I've been working on a project, and have been charged with designing the projects GUI front-end. I'm coding in Java and using the Swing toolkit. Usability-wise, the GUI front-end follows all of Nielsen's heuristics. Users can easily get to where they want to go through the click of a button / JComboBox. Essentially, in Swing terms, what happens is their actions drive the creation/deletion of custom panels.

The GUI is coming along fine for the most part. However, I have to admit to being utterly dismayed at the tight web of dependencies my code is being smothered in.

The main problem that I've encountered, that I haven't been able to fix as of yet, is how to keep a reference to the panels/buttons being changed.

I'll give an example:

Say there's a button A

Say there's a panel B displaying picture C

Say there's another picture D (not currently being displayed by panel B)

When user clicks A, panel B should remove picture C and display picture D

My question is, what's the best way of keeping track of panel B? Since I need a global point of access to panel B, my solution has so far been to just shoehorn it into a static variable, and access it through a series of static getters and setters. And this static variable is usually stored in the reference's original class. I.e. UserPanel has a static variable that stores a reference to itself.

Is there an easy, tried-and-true way of dealing with these kinds of situations? Like my GUI works fine, but it is not modular and/or robust at all. To add to this, the dreaded 'cyclical dependencies' issue that's shunned by so many programmers is out here in full effect. I'm fairly new to development and just want to make sure that my code will be fairly extensible and won't cause much of a headache to the next person that decides to get a try at it.

I know there's loads of books out there that probably have a nice elegant solution to this, but unfortunately I just don't have the time to leisure read right now. I need something that's quick and dirty.

Thanks in advance

  • Learning to make things right can seldom be achieved "quick and dirty". And I don't understand where you have any cyclic dependencies in your example. – Doc Brown Jun 29 '13 at 18:31
  • I didn't give that in my example, but it's certainly an issue in my code. Sorry I didn't mean to have a patronizing attitude towards the craft. I know its difficult. I was just wondering if somebody has a better solution to this. – tuba09 Jun 29 '13 at 18:46
  • 1
    Am I correct in assuming panel B is an instance of UserPanel and UserPanel is a subclass of JPanel? Why did you choose a static field instead of passing the reference around? – user2313838 Jun 29 '13 at 20:44
  • I guess for the convenience. It's a hell of a lot easier to just do UserPanel.getRef() than passing the ref down a series of constructors and local variables. There's areas where doing this is unavoidable (i.e. I can't pass down my ref to the constructor because it doesn't exist yet) but not in all areas. I guess that's just one more nit to pick. Thanks for the insight. – tuba09 Jun 29 '13 at 21:08
  • 1
    possible duplicate of How do I maintain states – Jim G. Sep 29 '13 at 4:15

have panel B add an ActionListener to Button A that (calls a method of B that) does the modifications

this way you don't need to keep access (this is done implicitly by the actionlistener)

then B should only know about the pictures it is displaying,

and the parent panel of B and A just needs to know that B is listening to A

  • I'll certainly look into this. I've never understood how listeners worked, but it looks like they could be what I'm looking for. Thank you. – tuba09 Jun 29 '13 at 19:05

Have you heard of the MVC web layer architecture? Well, that's flat out wrong. MVC is a modular GUI design. It was invented with Smaltalk and helped establish OOP as 'the' way to write GUI applications.

In short, you write model objects that hold whatever information is needed, start with the "document", but also anywhere you have to show a list, or input some complex data, or so. There should be some core API shared by all (or most) models, but it's ok to add some methods only where the make sense.

Then the view objects are those that handle GUI widgets, controllers, etc. to show the content of the model(s). Some views are generic and can show almost any model, others are more specific and can be paired only to some subset of model classes.

Lastly the controllers. Some frameworks omit these, or make them very thin. But in most cases it's better not to allow the views modify directly model data, it's better to specialize actions in model objects. This separation typically allows better reuse, a single view can be used in different ways with different controllers.

Note that it's not a layered architecture, each of the different modules in your application will typically have at least one of these trios, but hopefully only a small extra code for each, inheriting most of the behavior from more generic classes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.