Just remembered that I never responded to this statement from Daniel
OConnor <[EMAIL PROTECTED]>, written on Thu, 30 Dec 1999
18:01:04 -0500:
> So "base classes" don't become ejbs; only leaf classes do. You
> can even use common code--just put it in an ordinary java class
> that multiple beans use.
Thanks very much, first of all, for the advice.
My problem is with reuse. I'm in a group whose output is useless unless
it is extended. We make a "product" that our consultants then use as a
starting point from which to develop a customer solution. Consequently,
our "product" is incomplete, and must be extended to be valuable at all.
So, when we're done, *our* leaf classes--which we would ideally leave
concrete, since they're often all you need--become the consultants'
*base* classes. In a perfect world, we'd like to write the bulk of the
EJB work, and just have consultants extend it briefly, using CMP
wherever possible, so that the end result is lots of work by our group
and minimal work by our consultants. This is basic software reuse.
Unfortunately, the EJB specification does not allow for this kind of
easy extension-based reuse at all, and it's <polite cough/> pissing me
off.
Let's take an example. Suppose as part of my product I release a .jar
file containing the following classes:
Party.class
Individual.class
Organization.class
Employee.class
Company.class
Company logically should extend Organization; Employee should logically
extend Individual; and both Individual and Organization should logically
extend Party. Simple.
Now, if I were just using plain-vanilla Java, there's nothing
complicated about this: I hand this .jar to a consultant who promptly
subclasses Employee so he can capture the requirements of the customer
solution--e.g. he might create a new class, PartTimeEmployee, that would
extend Employee. When he instantiates a new PartTimeEmployee, he can
pass it to methods expecting a Party as an argument, or to methods
expecting an Individual as an argument--in short, all the stuff that OO
programming is good for.
Now suppose that I want to move this model into the EJB world.
According to the EJB specification and the (probably sound) advice given
above, if PartTimeEmployee is a leaf class--which it is--and all the
classes I just handed over to my consultant are abstract--which it's
looking like they have to be--then all of the classes in my .jar should
themselves *NOT* be EJBs, since they cannot be extended directly, and
since in the ultimate class hierarchy they will be base classes.
So your "common code" workaround seems to be for me to produce solely
interfaces (!) named Party, Individual, etc. and accompanying classes
named things like PartySupport, IndividualSupport, etc.; and for my
consultant, who, I must point out, in the old world would get something
he could just extend, to write a new EJB entity bean named
PartTimeEmployee from scratch, carefully implementing my Employee
interface, and making sure that he delegates as many operations as
possible to the EmployeeSupport class, which he is also responsible for
wrapping.
{brief pause}
ICK! IMNSHO, this *kills* reuse. I can get some reuse by using all
sorts of workarounds, but if my company goes with EJB, I've just made my
group's mission harder to perform.
Has anyone lived through this? Or are all EJB projects tackled by
members of this list so far simply one-off client solutions without any
intention of reuse of the beans involved?
Desperate,
Laird
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
