Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Best design - you pick

 
Christopher Brooks
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Excuse me, I did originally post this question in the Swing forum but felt it was more appropriate here...
I am having trouble deciding how to go about controlling the objects in my application. I want to have a JDesktopPane which when selecting menu options will spawn internal frames. The internal frames should themselves be able to spawn other internal frames.
Anyway I came up with a partial solution. In my GUI_DesktopPane class I have menu items and then also the following methods:

I then have various classes like GUI_MemberStatus that extends JInternalFrame and implements ActionListener. Now what should I do about those "special" internal frames that need to spawn internal frames in the JDesktopPane as well?
Should I:
a) Make the createFrame method static, and use it from wherever
b) Pass a reference of GUI_DesktopPane into the "special" internal frames constructor. Create the new internal frame within a method of the "special" internal frame. Call the createFrame method using the new internal frame as a parameter.
c) Make the GUI_DesktopPane a singleton. Call getinstance().createFrame from wherever I want.
d) Go away, read a book on design patterns, pass my SCJP exam, get a job in IT and stop trying to be a part-time programmer
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would go with b), because it results in the loosest coupling. Your internal frames shouldn't depend on there being only one DesktopPane.
BTW, I would advice against the way you implemented the actionPerformed method - it violates the Single Choice Principle. That is, every time you add another menu entry, you need to add it to several distinct places, which is a bad thing. I would rather use one ActionListener per menu entry.
 
Christopher Brooks
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am glad you said b) because that's what I was leaning towards. I am not sure I understand your comment about the event handling. Do you mean that I should implement anonymous inner classes, so that the text "menuItem1" can appear in the same place in the source code?

instead of:
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, that's what I meant (though I don't think there is an ActionAdapter - you might want to use AbstractAction instead).
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you're into MVC stuff, your listeners will do no more than notify the controller of a user gesture, eg clicked a button or selected a menu. The controller will have the logic to decide what to do with that.
Also think about a menu item and a button that do the same thing. Do you want to create two listeners with identical code in them? Have any other ideas?
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Stan James:
If you're into MVC stuff, your listeners will do no more than notify the controller of a user gesture, eg clicked a button or selected a menu. The controller will have the logic to decide what to do with that.

Agreed.

Also think about a menu item and a button that do the same thing. Do you want to create two listeners with identical code in them? Have any other ideas?

Remember the listener (temporarily) and add it to both widgets? I am doing this regularly.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic