> -----Original Message-----
> From: Craig McClanahan [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 16, 2005 5:04 PM
> To: Struts Developers List; Dakota Jack
> Cc: [EMAIL PROTECTED]
> Subject: Re: POJO Actions and the ActionCommand interface
> (Re: Configuration inheritance, module init code)
>
>
> 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.
PMFJI, but I've seen so much of
public void MyExistingBusinessLogicClass extends Action {
public ActionForward execute(...) throws Exception {
... perform business logic directly in this method ...
... return web tier specific navigation value ...
}
}
that I would prefer
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 would be easier to refactor into something more appropriate.
My comment from the peanut gallery would be to concentrate on making
good patterns easy, and forget about trying to prevent bad patterns.
You can't make things idiot-proof because the idiots are too clever.
The best you can do is provide clear examples and try to make the
"right" way easier than the "wrong" way.
- George
--
The opinions expressed above are my own, and solely my responsibility.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
