Last week, we had the author of TDD for a Shopping Website LiveProject. Friday at 11am Ranch time, Steven Solomon will be hosting a live TDD session just for us. See for the agenda and registration link
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.
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.
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.
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).
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.
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.
SCJP, SCJD, SCWCD, OCPJBCD
You firghten me terribly. I would like to go home now. Here, take this tiny ad:
Free, earth friendly heat - from the CodeRanch trailboss