Hi Jon,
Hope all is well in Ireland.
Instead of inheritance, I try to apply the Strategy design pattern.
This usually results in a database table that is similar, if not
identical, in design to a single-table inheritance database table,
ie., it has a "type" field, usually an integer, however the EOModel
has no EOF inheritance artifiacts. The versatility and simplicity of
Strategy design pattern is more desirable and easier to maintain and
extend IMHO ....... very easy to add new behaviours. (or in American
English "behavior")
I will try to summarize briefly for anyone interested:
For example instead of EOF inheritance with an abstract Animal class
and subclasses Dog, Cat, Cow, Horse, etc. You could simply have a
concrete Animal class and an AnimalBehaviour interface.
AnimalBehaviour interface might have methods
walk, eat, run, speak, and attributes such as height, weight, color,
breed, kind
Then Animal implements AnimalBehaviour,
and to add more types, we just have the following, each with a
constructor that takes the Animal EO as a parameter.
DogBehaviour implements AnimalBehaviour
CatBehaviour implements AnimalBehaviour
CowBehaviour implements AnimalBehaviour
etc.
Usually I define properties such as
AnimalBehaviour.10=my.project.eof.DogBehaviour
AnimalBehaviour.20=my.project.eof.CatBehaviour
AnimalBehaviour.30=my.project.eof.CowBehaviour
and in the Animal.java EO class, I would have a lazy instantiated
protected behaviour method, for example:
protected AnimalBehaviour _behaviour;
/** @return the Strategy pattern class that implements the custom
behaviour specific to this type of program.
The instance is created and the program variable is set to
this. */
protected AnimalBehaviour behaviour() {
if ( _behaviour == null ) {
String propertyName = "AnimalBehaviour." + type();
String clazzName =
ERXProperties.stringForKey( propertyName );
if (clazzName == null) {
throw new RuntimeException("The property '" + propertyName + "' is
not defined!");
} //~ if (clazzName == null)
_behaviour =
( PersonBehavior )WKReflectionUtils.objectFromConstructor( clazzName,
this );
}
return _behaviour;
}
and in Animal.java (the EO class), I have the interface methods
implemented as follows for example:
public void speak() {
behaviour().speak();
}
You can have simple static factory methods to create various animal
types in your Animal.java ...... or create a property AnimalFactory
class if you like:
public static Animal createDog()
public static Animal createCat()
I have found this approach refreshing and easier to maintain and
extend as a project gets new feature requirements. Adding a new type
requires adding one class that implements the AnimalBehaviour and one
property to map the type to the behaviour class ....... nice and
clean and without touching the EOModel. You can even have a few
abstract superclasses to keep DRY on the Behaviour implementations,
for example AbstractBigWildCatBehaviour that can be used for
CheetahBehaviour, TigerBehaviour, LeopardBehaviour and
SnowLeopardBehaviour.
This approach works especially well when you have 100's or 1000's of
Behaviours ...... try doing 100's or 1000's with inheritance (never
mind EOModeling it and EOF manipulations).
The good news is that it is easy to convert existing Single-Table
inheritance to the above Strategy Design Pattern. No database changes
required. Just map existing 'type' integers to strategy Behaviour
classes. Of course you can have multiple behaviour classes (and types)
too if you want more granularity, for example a Leopard and
SnowLeopard may share the same speak() and eat() behaviour.
Anyway, that's my 2 cents!! :-) Learn more about Strategy Design
Pattern from Head First Java chapter 1 or one of the serious D.P. books
Regards, Kieran
On Sep 6, 2009, at 7:18 PM, Jon Nolan wrote:
I haven't used inheritance in years. My experience was that the
hassles you faced far outweighed the benefits of elegance of design.
I now have a project which begs for it. What say you? Do you use
inheritance or is my gut feeling correct in telling me to keep on
staying away?
Thanks,
Jon
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/kieran_lists%40mac.com
This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
