I think if we bent the technology for "miscreants" this far, we may
eventually go back to the typewriter and carbon paper.
Jack
On Wed, 16 Mar 2005 14:04:06 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> 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
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
