Re: Collection, enum or something else?
Mark Space wrote:
Todd wrote:
Hello,
Suppose one has a class called Shrub that has well-defined behavior
and state. Now suppose one wants to create references (pardon the
loose wording, hopefully this will become clear shortly) to shrubs of
the world by continent.
I think you might be over complicating things. What's the matter with:
public class Shrub
{
String name;
String continent;
or
Continent continent;
This type of reference is commonplace in ORM layers like Hibernate and OpenJPA.
Or something. I think you're over complicating things by using an enum,
for sure. There are probably not a finite list of shrubs that you want
to enumerate, and more will be discovered. My primary clue here was that
just a Shrub object was good enough inside your enum. If it is, then
you don't need the enum or a subclasse. "Prefer composition to
inheritance." And that's what I did. Rather than subclass or make an
enum, I just composed Shrug so that it had the property needed.
I guess an enum for the continents makes sense though. Unlikely that
any new continents will come along.
Don't continents have attributes? Names, populaces, nations, topographies,
relationships to each other?
This is not a challenge to Mark Space's excellent example, but an illustration
of how very amenable it is to enhancement, This sort of functionality
iteration is the heart of several very effective development styles.
Evolution is straightforward when you start with a clean, robust design.
Incremental advances are key, too - My suggestion focused on only one detail,
changing the type of 'continent'. I won't even think about linking 'name' to
Taxonomy until I'm sure Continent is right.
After-the-fact linkups like this are harder with inheritance models than with
composition models.
--
Lew