Here's one possibility that we (myself and Bob Schwartz (Hi, Bob!)) are
playing with here... It would only work for entity beans, because it relies
on primary key classes.
Say you have base bean Base, and a bean Sub which extends Base (I'm being
fast and loose with the word "extends" here; this is what I mean:
Base:
- BaseBusiness (common business method interface (see Monson-Haefel's book))
- BaseRemote extends BaseBusiness (remote interface)
- BaseImpl implements BaseBusiness (bean implementation class)
- BaseHome (home interface)
- BasePK (primary key class)
Sub:
- SubBusiness extends BaseBusiness (common business method interface (see
Monson-Haefel's book))
- SubRemote extends SubBusiness (remote interface)
- SubImpl implements SubBusiness (bean implementation class)
- SubHome (home interface)
- SubPK extends BasePK (primary key class)
)
Without getting into implementation details, assume that BasePK is "smart",
and has a getBeanReference() method, which returns a reference to the entity
bean instance that corresponds to that particular PK instance (the
getBeanReference method uses reflection to return the proper bean reference
for Base, as well as any beans which extend Base).
Now, if I pass PKs to and from methods (instead of actual bean references),
I can use the PKs to get polymorphic behavior for methods on the entity
beans. For example, if BaseBusiness has a method getTotalCost(), and Base
and Sub each provide different implementations for getTotalCost(), I can do
this:
public class BasePK
{
//...
public BaseBusiness getBeanReference()
{
//...
}
public int getTotalCost()
{
BaseBusiness base = getBeanReference();
return base.getTotalCost();
}
//...
}
...which allows me to do this:
// ...
BasePK base = getBase(); // Assume this returns a BasePK
BasePK sub = getSub(); // Assume this returns a SubPK
int baseTotalCost = base.getTotalCost(); // gets the total cost of the Base
bean
int subTotalCost = sub.getTotalCost(); // gets the total cost of the Sub
bean
//...
Ta da! Entity bean polymorphism.
I'm sure there's some patterns somewhere that would help explain all this,
but I don't know what they are, except that I suppose the PKs act as "Proxy"
objects to the actual bean references. Is anyone doing anything similar to
this to achieve polymorphic behavior for entity beans, or am I totally
crazy?
KurtC
-----Original Message-----
From: Pedro Garcia Lopez [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 20, 2000 5:55 PM
To: [EMAIL PROTECTED]
Subject: EJB Inheritance, polymorphism and generic code
Hello,
I want to create generic code and an extensible architecture.
I am getting stuck and I think it is not possible in the EJB model.
Let�s say, I have a base class P with a method (contract) hello(). I can
then create classes A, B, C inheriting from P and then create generic
and extensible code using polymorphism.
With Remote classes inheritance is possible, but not for Home classes.
And of course this is a strong bottleneck, since the only way of
creating or obtaining a handle to a EJB is through its Home interface.
1) IObject objref = initial.lookup("reference");
2) PHome phome =
(PHome)PortableRemoteObject.narrow(objref,
PHome.class);
3) P pointer = (P)PortableRemoteObject.narrow(phome.create(),P.class);
4) System.out.println(pointer.hello());
If I use a reference to a EJB A that inherits from P, obviously I will
get a cast exception in line 2 (PHome and AHome are not related).
Is there any way to use polymorphism and generic code in the EJB model ?
Regards,
Pedro
===========================================================================
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".
===========================================================================
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".
