That
ability may or may not be needed. The different flavors of Persons here are
interchangable and integrated for a client that is willing to use both of them.
Now that is not related to the concept of inheritance itself, but I understand
it to be inherent to the concept of framework. Now if Client A and Client B
beans won't interact with each other (directly or indirectly), then it's
probably best to branch the projects before the very first release, wouldn't
it?. Charles, if you can shed some light on this it would be
superb.
Ellaborating a little bit more, inheritance as you
propose will yield partial reuse of state and behavior, and full reuse of
behavior contracts, but will still need for assembly/deployment descriptors to
be managed separatedly and potential errors will be difficult to trace and
debug(a stack trace showing an exception originated in a superclass actually
caused by a typo in a finder, etc.). I still feel that containment is the most
effective approach.
My
2c,
Juan Pablo Lorandi
Chief Software
Architect
Code Foundry Ltd.
Barberstown, Straffan, Co. Kildare, Ireland.
Tel: +353-1-6012050 Fax: +353-1-6012051
Mobile: +353-86-2157900
www.codefoundry.com
Disclaimer:
Opinions expressed are entirely
personal and bear no relevance to opinions held by my employer.
Code Foundry Ltd.'s opinion is that I
should get back to work.
-----Original Message-----Juan,
From: Victor Langelo [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 24, 2002 5:29 PM
To: Juan Pablo Lorandi
Cc: [EMAIL PROTECTED]
Subject: Re: Using Entity Beans for multiple projects
I don't believe the problem your trying to solve with your example is related to Charles original question. There is no need to return all persons with or without addresses. Unless I misread the original post, Client A doesn't what contacts from Client B and vise versa.
--Victor
Juan Pablo Lorandi wrote:
001501c27b78$0b690880$0500a8c0@rifle" type="cite">How polite of you Victor. I'll try to fundament what I stated, and of course you can backup your points qualifying mine as bullshit.An object is (state + behavior). In EBs, behavior is never contained solely in the class that implements the EntityBean interface.Merely extending a class won't make it acquire all behavior defined for the supercomponent(because they're components, not classes). For the point Charles raised, reusing a component without resigning performance is not an easy task. Now, perhaps I'm missing something here, but lets assume:base class:public abstract class PersonEJB implements EntityBean {......}class for customer 1:public abstract class HomelessPersonEJB extends PersonEJB {...public abstract String getName();public abstract void setName(String name);...}class for customer 2:public abstract class HomeowningPersonEJB extends HomelessPersonEJB {...public abstract String getAddress();public abstract void setAddress();...}So far, so good. Now make a SLSB that returns all persons, with or without address; y ou will need to:A) Have the variations of Person in different DB tables and make some sort of union (in the SLSB or the SQL) to join all of those.B) Keep everything in the same table, with some fields being used or not depending on the implementation.As the hierarchy of objects becomes bigger, the total cost of the first option arises enormously. For this particular case, which is very simple, I'd just code a dual purpose bean with different interfaces, assembly and deployment descriptors, all pointing to the same DB table. I'd add a Role field or something like that to discover the type of the Bean at run time.What you definetly cannot do is: inherit the code (or pseudo code) for the finders and most of the assembly descriptor(and optionally override parts of it). So basically, you've inherited the behavior portion you have in the Bean class, possibly you'd do the same for client interfaces, but you have to manage N different assembly and deployment descriptors that also define the behavior of your bean.The last option, which is somehow a compromise option is containment/agregation. It allows black-box reuse and therefore it allows to seize not only the remote interfaces but also the deployment descriptors, therefore classes for customer 1 and 2 result in:class for customer 1:public abstract class HomelessPersonEJB implements EntityBean {...public abstract PersonPK getPersonPK();public abstract void setPersonPK();public abstract String getName();public abstract void setName(String name);...}Remote interface for customer 1:public interface HomelessPerson extends Person {public void setName(String name);public String getName();}or:public interface HomelessPerson extends EJBObject {public Person getPerson();public void setName(String name);public String getName();}with the possible variation of:public interface ContainedPerson extends EJBObject {public Person getPerson();}public HomelessPerson extends ContainedPerson {public void setName(String name);public String getName();}Finally:class for customer 2:public abstract class HomeowningPerson implements EntityBean {...public abstract PersonPK getPersonPK();public abstract void setPersonPK();public abstract String getName();public abstract void setName(String name);public abstract String getAddress();public abstract void setAddress();...}Now, should you need to change a finder for the Person EJB, you need to touch only the assembly/deployment descriptors for Person, and voil� you've got it working with all the "extending" components. My point is: EJBs are components. Java inheritance may help reuse, but it doesn't go all the way. Therefore I'd prefer another OO approach that isn't solely based in inheritance to solve the problem Charles presented to us.Now, from my experience, and for my very own reasons(rotation of coders mostly), I usually prefer containment/agregation over inheritance. That's MY opinion and mine alone; you may think differently and that's superb. But I fail to see how slating me is going to prove you point.My 2c,Juan Pablo LorandiChief Software ArchitectCode Foundry Ltd.
Barberstown, Straffan, Co. Kildare, Ireland.
Tel: +353-1-6012050 Fax: +353-1-6012051
Mobile: +353-86-2157900
www.codefoundry.com
