I prefer using the Strategy Design Pattern instead of inheritance
whenever possible ...... using the Strategy Design Pattern will
result in one Domain entity and the internal logic/behaviours can be
implemented by a single interface or multiple interfaces allowing you
a flexible logic building block architecture. Inheritance is fine,
but it is all too commonly used and ends up painting one into a corner.
If you need more pointers on how you would implement Strategy design
pattern in an easy to maintain way for an enterprise object let me know.
Regards, Kieran
On Aug 17, 2007, at 11:46 AM, Riccardo De Menna wrote:
Hi Guido,
I might have badly explained my issue. I have successfully used EO
inheritance in another context, but my aim here is exactly the
opposite. I don't want to model my DB with all sort of empty tables
for every possible domain ending (there are more than 200 different
country codes and such).
I'm perfectly fine with one single table holding domain info... I
simply want to fetch from it and receive specific subclasses of the
main "domain" class. These would simply differ from the common
superclass in the custom logic in them and NOT in the fields they
hold. Let's say for example that the DotCOM domain subclass would
validate domains up to 63 chars in length while the DotEU would
start bitching for anything longer than 25 or so, even though the
table holds any length.
That said I'm ordering Chuck's book anyway but it will take some
time to get my hands on it since I'm traveling through Europe atm.
If someone could simply tell me "you can't do it" or "you do it by
subclassing this" or such it would speed me up a lot...
Cheers,
Ric
_______________________________________________
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]
