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.
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.
> <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.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
