AMEN! +42
On Thu, 17 Mar 2005 08:25:04 -0600, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > -----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] > > -- "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]
