Re: Inheritance...
Re: Inheritance...
- Subject: Re: Inheritance...
- From: Kieran Kelleher <email@hidden>
- Date: Thu, 8 May 2008 13:39:14 -0400
On May 8, 2008, at 11:29 AM, Florijan Stamenkovic wrote:
On May 08, 2008, at 10:47, Kieran Kelleher wrote:
15 entities with 30 max records per entity = max 450
records. ...... even with 100 attributes this is probably trivial
data size, so I would not go out of my way to avoid Single Table
inheritance for the sake of avoiding a lot of null fields in the
database.
Point taken. Though I was more worried about the ugliness then
anything else...
If it was me, for such a complex inheritance hierarchy, I would use
the Strategy Design pattern and not use inheritance at all since I
have found that complex inheritance can be a PITA to refactor as
the requirements change/grow over life of the app.... and the bonus
is the complete avoidance of EOF inheritance bugs :-)
I don't really understand what you mean... Isn't Strategy used to
easily swap functionalities, processing code? How does that work
with storing data? Are you thinking of using a single attribute to
store all sorts of things in it, depending on the type of record, or
something? If so, how does that deal with relationships? I've never
done this, so I don't get what you're saying...
In brief, the entity has a type field (just like single table
inheritance has) that determines which Strategy class applies to the
instance. Usually I use an integer and I have a property that
determines the behaviour class in Properties, like this
strategy.entityname.10=com.domain.BehaviourClassOne
strategy.entityname.20=com.domain.BehaviourClassTwo
etc.
The entity has a behaviour method that lazily initialize the behaviour
class with a constructor that takes the entity instance as an argument.
Usually I have a single static factory method in the entity that takes
the type as an argument. The factory creates and instance sets the
type and then calls initialize(). initialize() delegates to the
behaviour class' initialize() method.
The behaviour classes all implement a common interface. One behaviour
class exists for each Object type you want to model. Essentially, you
can add more object types and change applicable attributes without
touching your eomodel/database.
How are attributes handled ......... well, every entity has all the
attributes from EOF's perspective .... however the behaviour strategy
class associated with each Object Type returns an NSArray<String> of
applicableAttributes(). In your WOComponents a simple conditional that
checks whether an attribute is in the current object's
applicableAttributes() decides whether to display or not to display
the attribute in view/edit components.
that's the gist of it ..... I do use inheritance for simple cases, but
when a lot of various object types are called for I find this much
easier and more flexible to maintain and add functionality than a
multi-tier EOF inheritance of dozens of different classes ..... all
the overrides is enough to make one's head spin!
In any case, take the path of least resistance to get your project
done. You can easily refactor single table inheritance into a single
entity with Strategy Design pattern later if your inheritance
hierarchy is making you tear your hair out. ;-)
Also, there might be opportunity to segment some lesser used
property groups into optional related objects if the domain model
lends itself to that
Not really, would only make it messier in my case...
F
_______________________________________________
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