• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: EOF inheritance
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: EOF inheritance


  • Subject: Re: EOF inheritance
  • From: Jon Nolan <email@hidden>
  • Date: Tue, 08 Sep 2009 12:19:51 -0600
  • Organization: Loch Garman

Thanks Kieran.

I use the strategy design pattern fairly often (I draw the line at implementing MutatedSeaBass.) I'll have to think more about using it with entities over inheritance. It definitely has merit.

Kieran Kelleher wrote:
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@hidden <mailto:email@hidden>)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden


_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
References: 
 >EOF inheritance (From: Jon Nolan <email@hidden>)
 >Re: EOF inheritance (From: Kieran Kelleher <email@hidden>)

  • Prev by Date: Project Wonder Libs missing
  • Next by Date: Re: Project Wonder Libs missing
  • Previous by thread: Re: EOF inheritance
  • Next by thread: How to make the AjaxSubmit button hold until the action binding its executed?
  • Index(es):
    • Date
    • Thread