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; you 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 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 Pablo Lorandi wrote:
From: Victor Langelo [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 24, 2002 2:59 PM
To: Juan Pablo Lorandi
Cc: [EMAIL PROTECTED]
Subject: Re: Using Entity Beans for multiple projects
000501c27b63$62c7b870$0500a8c0@rifle" type="cite">This is Bull S---. Charles' use of inheritance is one of the very classic uses of OO languages, i.e. a framework. The real problem here the limitations of the IDE.I recommend you consider using different classes for Client A
and Client B. It is true that this will prevent the automatic
reuse of any changes that you make to these classes in the
future, but it will significantly reduce the complexity of
extending the class in a manner that is consistent with the
needs of both clients.
I tend to agree. This has always been the major drawback of white-box
reuse, inheritance, in OO enabled languages, especially whenever the
"owner" or coder that maintains the class changes.
--Victor
