OO, Pointers to other objects, and cursors

[DaWickedRebel]

No, not a Jeopardy answer, though it is a strange combination.

I'm a new disciple of Object Oriented Design, and I've taken on the task of refactoring a quagmire of a Java application. It's quite a project as even this poorly designed app has over 100 classes, all crammed with repeating and rigid code. To avoid going insane, I'm just trying to take it apart piece by piece, and hopefully it will make each subsequent step easier.

Sorry to ramble, but I've been reading this site for a while now and can tell that those of you who post replies are very well versed in this subject so I hope you can help me to better grasp good design principles and such.

My question is this:

I have a class MyActionListener that will handle commands which may be triggered from a Toolbar on my main JFrame, from MenuItems on my main JFrame, or from Popup menus triggered by right-clicking in any of my JInternalFrames which may be created during the app's execution.

The commands are the same from each, just basically more than one way for the user to trigger the events.

When a certain type of event is triggered, I want to set a WAIT_CURSOR over my entire application until the process triggered is complete.

Without passing pointers to my main JFrame class into MyActionListener (which I know is bad design), what would be the cleanest and most object-oriented method to achieve this?

Thanks for helping a newbie!

Rich

 

[stevexff]

The command[GoF] pattern you are using is certainly the correct one for this situation. But I can't help you on the WAIT_CURSOR, I'm afraid...

 

[EdwardJS024]

Steves right, the command pattern seems right for this situation. Commands more closely relates to the concept of use-cases. So you might have commands for "SaveCommand", "DeleteCommand", "Undo".

With that said, implement these objects at the Application layer. The App layer ogranizes and coordinates the workflow of the specific app. The theory follows that entire applications can be rewritten, new features added, removed simply by resuing the Domain Layer but layering it with new usecase that reuse the domain objects, just coordinationg workflow logic differently.

As for the wait-cursor thing. That is an app specific thing also that appears for certain actions taken. My best bet is to implement this at the UI level. let the UI turn this on/off just before every command is executed against the app layer.

EdwardJS

 

[DaWickedRebel]

Thanks Steve and Ed, your advice is golden.

I have a question though. It seems to be my biggest problem and sticking point. Suppose that one of my commands, when executed, would activate/deactivate buttons on a toolbar that is otherwise unrelated to the command. For example, executing the 'Save' command from a drop down menu would make the Save button on my toolbar inactive. In keeping with object oriented approaches, how do you 'give' the Save command knowledge of the toolbar in question? Do I have to pass pointers around or store it in some organizing class. This is just an example but the concept comes up time and time again for me.

Thanks for your help / advice.

Rich

 

[EdwardJS024]

Hi Rich,
no you do not give any additional responsibilities to the SaveCommand, you'll be violating cohesion here. Look at my blog for my details:

http://softwaretheory.blogspot.com/

 

[stevexff]

Ed

Had a look at the blog - useful tips. Couldn't toggleSaveButton() be more generic? Like toggleControl() for example? Also, (A. Pedant writes), it doesn't actually toggle, it deactivates...

private void toggleControl(Control aControl) {
   aControl.Active = !aControl.Active;
}

Then when you make a UI change that makes Save a valid option again, you can just re-execute it to flip it back on.

 

[EdwardJS024]

Yes, sounds just right.
hope that helps

 

[stevexff]

Mmm. Thought about it some more, and 'toggle' isn't such a great idea after all. You need to be explicit about whether you are setting it on or off, as any given event handler doesn't (and shouldn't) know about the current status of the control, just what it needs to be set to as a result of the event being fired. The toggle thing is just too arbitrary.

 

[EdwardJS024]

It really dies'nt matter, the example listed at my blog was meant to be extremely simplistic and serve as no enterprise solution. I was focused more on distributing work flow logic.

hmm, then again I should change that to fall inline with what you suggested. thanks

Edward JS

 

[stevexff]

I wasn't picking holes in the blog. At first I thought that toggling was a useful thing to do, but after a bit more thought I realised that it was a disaster waiting to happen...

 

[zooxmusic]

Hi DaWicked Rebel,
I actually found an article a while back that I haven't actually implemented yet so I don't know the ins and outs but it was very interesting and I plan to do this soon. Try this.

http://www.javaworld.com/javaworld/javatips/jw-javatip87.html

Brian


Spend like you don't need the money,
love like you've never been hurt and dance like nobody's watching!