Chip,
What a wonderful idea. I used the template method pattern in the past and
it's a good approach for reuse and is very appropriate for this case. I like
the advantage of both pre and post processing, and of enforcing the order.
My original thinking was that I rather avoid defining new APIs so that our
users remain within the EJB realm. I guess this is not that important and I
can define parallel methods with names that are easy to match to the EJB
ones. In particular our technology is called internally cdk (component
development kit) and we can simply call the "hook" methods cdkLoad, cdkSave,
...
Thanks a lot for a wise advise!
Doron
> -----Original Message-----
> From: Chip Wilson [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, September 09, 1999 7:30 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: enhancing app servers using CMP vs. BMP
>
>
> see below
>
> Doron Somer wrote:
>
> >
> >
> > One of the things our base class does is some generic
> conversions in ejbLoad
> > and ejbSave (to handle persistnece of CORBA object
> references and alike) and
> > we may need to provide some generic behavior in the other EntityBean
> > methods. Typically I don't think the developers using our
> platform will need
> > to implement the EntityBean methods themselves, but if they
> do, we will
> > require them to invoke first the base class' version of the
> methods. So for
> > example an implementation of ejbLoad will look like this:
> >
> > super.ejbLoad();
> > <additional behavior>
> >
> > In the future we can code generate the initial
> implementation of a bean that
> > will include extending our base class and a skeleton for this
> > implementation, to avoid errors in forgetting to make the
> call to the base
> > class.
> >
> > I'd like to get feedback for this approach, and whether you
> see any issues
> > with using CMP this way.
> >
>
> I would favor implementing ejbLoad (etc.) in the superclass
> using the template
> method pattern [Gamma p. 325], and specifying that it not be
> overridden,
> possibly by making it final. That way you can enforce the
> usage. If developers
> need to add behavior, you have provided a "hook" through a
> protected no-op
> method that they can override. This will also allow you to
> move around the hook
> within the superclass method if you have a need to do
> something after the
> subclass, for example.
>
===========================================================================
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".
