Polymorphism or conditionals ?

[Mihai Radulescu]

Hi,

I have a dilemma, to refactoring or not.
I can give a simple example : the buttons & menus action listener. It is possible to create an action listener for each button or to have the same listener for a group of actions and to use some conditionals(and the action command feature) to decide about the running action.
The first technique is very "object oriented"(replace conditional with polymorphism) but it brings a lot of code - heavy to read/understand/maintain
The second look has a "structural programming" touch but it is more compact and easy to understand, ...

So to have more "object oriented" code - increase complexity or to have a compact "structural programming" looking code. I have the feeling that the truth is somewhere in the middle.

What you guys thinking ?


Regards, Mihai.

[Pawel Poltorak]

Hi Mihai,

From what I have understood from your mail you want to use ActionListener instances. Have you considered using javax.swing.Action instances? This way you have single ActionListener, which you can (using setAction() method) apply to many ui components. You can also set action properties, such as mnemonic, accelerator, icon, tooltip etc. which will be used when setting ui component properties.

Best Regards,
Pawel

[Mihai Radulescu]

Hi Pawel,

I just read an article about Actions, I will consider it. Thanks for the tip.


Regards,
Mihai.

[Lara McCarver]

A fourth possibility is to use a separate listener for each button or menu, but in places where code sharing is possible, have the listeners use a static method somewhere, or have the listeners call a common method in the parent object.

In my opinion, Java is more naturally structured to have separate listeners for each button and menu item. For example, in Core Java, they try to show how different buttons can share the same listener but there is no natural mechanism to differentiate the buttons. I think they end up using the string which is on the button, but if you ever want to internationalize your product, you will end up with different names for different buttons, so I don't like that solution.

I don't really think the code is harder to maintain with separate listeners for each button. It might be a little bigger, but that's not a real problem. What makes code hard to maintain is when you have the same code being used in three subtly different ways. Then changing that code to solve one problem can break the existing working solutions for the other cases.

Lara

[Mihai Radulescu]

Yeep,

I think that you people have right,
Silly me. I was all clear. I don't know why choose this solution.
More than that if I choose to use the same listener for more actions, I also give to one listener to much responsibilities - more chances to get changed, also If I need to change only one action I must modify the entire listener(the open close principle).

So in one word , it was a bad idea.



Regards,
Mihai.
[ February 15, 2006: Message edited by: Mihai Radulescu ]

[Pawel Poltorak]

Hello,

I would consider using actions anyway. Action extends ActionListener therefore in fact is a separate listener, not per button/menu item, but per functionality. The same action can be used for button and menu item which are an access point to some application functions. Additional advantage is that Action provides a common place to define ui component properties.

For example in my URLyBird I use menu and toolbar. I use one Action instance to handle 'Book' option from menu and tooolbar. This way I don't have to create separate listeners for menu and toolbar components.

Best Regards,
Pawel

[Aruneesh Salhotra]

I was going to have one ActionListener for saw all the menu items in the tool bar.

Though I have 3 toolbars depending on which mode the application is open in, but I have one action listener, and I just change the actionCommand for the menu items and perform if/then/else.

Is that too simple and probably requires some OO brought in.

[Mihai Radulescu]

Hi, Aruneesh

You just make the same mistake like me before. I think that the Action solution better (you can read also reliable).

By example lets say that you have a listener for three different events. For the moment is OK but in the future you may need to extend the functionality and to modify the action only for one event type.
If you have the same listener for all you must change the common class, but if you have separate event for each listener you just create a new one (and you register it), all of this without to alter the old (existent class). This is know like the open - close principle , open for extension close for changes.
Thats one reason why the Actions solution (one action for each event) is better than one Listern for all events.


Regards,
Mihai