When populating a bean for various select lists, what are the pros and cons of using one generic bean like Struts' LabelValueBean versus separate beans for different types of lists? i.e. StateBean, CityBean, CountryBean, etc.
Maybe this question might have a better chance of getting answered in the Struts forum.
In general, the realization of StateBean, CityBean, CountryBean, etc. would only be worth while if there was some inherently different behavior that each one would implement internally while servicing an interface like LabelValueBean. Given that LabelValueBean has a clearly defined responsibility adding other functionality could protentially violate the Single Responsibility Principle. Sometimes it may be simple enough to add a LabelValueBean-like interface to an existing object - however that would "contaminate" StateBean, CityBean, CountryBean with concerns that only matter in the context of Struts. It would be better to create decorator classes for the StateBean, CityBean, CountryBean and make it the responsibility of the decorator classes to expose a LabelValueBean-like interface. That way it only the decorator classes are concerned with Struts.
Originally posted by Vladas Razas: I think that would be more of adapter pattern. I imagine decorators silently adding some behaviour to object without changing their interface. Sorry if I am wrong.
No, you are right.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Vladas Razas: Sorry if I am wrong.
No, you are quite correct, I should have referenced the adapter. It seems that an adapter can also introduce new responsibilities (only available through the adapter) without getting a decorator involved.
[GOF]: Adapter: A decorator is different from an adapter in that a decorator only changes an object's responsibilities, not its interface; an adapter will give an object a completely new interface. Decorator: enhances another object without changing its interface. A decorator is thus more transparent to the application than an adapter is. As a consequence, Decorator supports recursive composition, which isn't possible with pure adapters.
He was giving me directions and I was powerless to resist. I cannot resist this tiny ad: