See mix-ins!
> -----Original Message-----
> From: Craig McClanahan [mailto:[EMAIL PROTECTED]
===/////===
>
>
> On Wed, 16 Mar 2005 10:08:15 -0800, Dakota Jack
> <[EMAIL PROTECTED]> wrote:
> > <SNIP>
> > On Wed, 16 Mar 2005 09:54:48 -0800, Craig McClanahan
> <[EMAIL PROTECTED]> wrote:
> > > I agree with Ted, and the reasoning he states. Indeed, in this
> > > particular respect, Action *should* be inflexible because
> making it an
> > > interface would encourage you to use it incorrectly.
> > </SNIP>
> >
> > How is an interface with the same signature more flexible in any
> > relevant sense here? I don't see that. How could an
> extension of an
> > Action class be more or less encouraging in how you use it
> "correctly"
> > or "incorrectly" than an implementation of an Action interface? I
> > don't see what this could mean.
> >
>
> One wrong way to use Action (if it were an interface) is:
>
> public void MyExistingBusinessLogicClass implements Action {
> ... non-Struts-related business methods ...
> public ActionForward execute(...) throws Exception {
> ... call business logic methods in this class ...
> ... return web tier specific navigation value ...
> }
> }
>
> because it binds your existing business logic to Struts (and therefore
> servlet) APIs when it should be completely independent.
>
Consider also this anti-pattern
public void MyExistingBusinessLogicClass
implements Action, javax.ejb.SessionBean {
... non-Struts-related business methods ...
public ActionForward execute(...) throws Exception {
// try to invoke other methods of this SessionBean
// if you can deploy it successfully!!!!
}
}
This is a disaster because EJB container is complete different
from the Webapp container in J2EE 1.[34] containers. They
are usually two different classloaders: webapp
container is trying to invoke an EJB container outside
itside its correct environment.
> The corresponding right way:
>
> public class MyExistingBusinessLogicClass {
> ... non-Struts-related methods ...
> }
>
> public void MyStrutsAction extends Action {
> public ActionForward execute(...) throws Exception {
> ... acquire reference to MyExistingBusinessLogicClass ...
> ... configure appropriately based on form inputs ...
> ... delegate work to existing business logic methods ...
> ... return appropriate navigation result ...
> }
> }
>
> The "wrong way" version above is not possible (with Action as a base
> class), due to single inheritance in Java.
>
> Note that neither approach prevents a different form of "wrong way":
>
> public void MyExistingBusinessLogicClass extends Action {
> public ActionForward execute(...) throws Exception {
> ... perform business logic directly in this method ...
> ... return web tier specific navigation value ...
> }
> }
>
> so yes, Action as a class can be misused ... but not in as
> many different ways.
>
This is example, which Craig peadogogical provided above, is the
reason that books like "Core J2EE Patterns" and the blueprints
were written to help architects/developer design and build
functioning applications. BTW: The solution, circa 2004, is to use a
business delegate or use service locator and service to worker
patterns. In 2005 you can replace your business delegate and service
locator with service bean looked up from an assembler (IoC container).
The container makes your services available to the web application.
The services can be implemented to call EJBs or call OR/M or whatever
you need for business logic.
> > <SNIP>
> > > History lesson time.
> > >
> > > Prior to Struts 0.5 (in 2000-2001), ActionForm was indeed an
> > > interface. It became clear that a large majority of the
> audience for
> > > Struts was misusing it, by making their VO beans "implement
> > > ActionForm" -- violating the principle that ActionForm
> was, and is,
> > > part of the View tier (not the Model tier. It was
> changed into a base
> > > class precisely to avoid this.
> > >
> > > As you might imagine, this was a controversial decision
> then. But I'm
> > > sure glad we did it.
> > </SNIP>
> >
> > I also do not see the point in this. Why cannot you misuse
> a class to
> > precisely the extent you can misuse an interface?
>
> Same argument as above, but this time using existing value objects or
> data transfer objects from your model tier, and making them "implement
> ActionForm". This was happening a *lot* in the early days, and
> changing to a base class fixed at least this misuse scenario.
>
Craig's solution to restrict the Action and ActionForm to abstract
classes was his best design decision when he developed the Struts
framework. As I alluded to above, many of the principals of the
J2EE platform were not understand by everyone, so I think, he
helped prevent software oblivions for a lot of web application
developers at the expense of programmatic frustration to the
novices.
Regardlessly of misusing a class or interface the fact of the matter
is that you got to know what platform you are architecting on.
If you do not understand the concept tiers and how it applies
in J2EE containers (either EJB and Web) then you can get
confused.
> It is also instructive to observe the growing popularity (in
> enterprise Java circles) of IoC approaches to instantiating business
> and service objects (Spring, Hivemind, PicoContainer, etc.), which are
> implemented as POJOs and composed via dependency injection. I suspect
> that people who like this style (as opposed to more rigid API
> frameworks) in the model and business tiers are also likely to prefer
> it in the web tier as well.
>
> Craig
==/////==
This is me. Out.
--
Peter Pilgrim
Operations/IT - Credit Suisse First Boston,
Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom
Tel: +44-(0)207-883-4497
==============================================================================
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==============================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
