The helper, for purposes of comparison, just has the abstract methods that the abstract class requires. You have other options, of course, but that is the basic idea. This seemingly small difference makes all the difference, however. The basic problems with the Template Method that chain fights could be gotten rid of without chain by using Strategy. However, since the decision has been made to solve the Template Method problems with chain, you can really clear the air and use Strategy with chain. There is no need to keep the problem that chain solves just because you had it before. This make sense to you?
Particulars follow. The basic "drill" out *there* among framework architects on the differences is as follows, I think: The only real advantage to the Template Method pattern is that you can make the template, abstarct class work simply by instantiating a concrete subclass. You don't have to manage a relationship between the class and business objects. First, this advantage is irrelevant when running in an IoC container, so down the road the Template Method pattern hopefully would not have a single advantage. Second, the advantages of the Strategy pattern are considerable in contrast: a. The strategy can be changed at runtime. Concrete inheritance is defined statically and is inflexible. Composition is better. b. Multiple strategies might be necessary. With concrete inheritance all of them are linked. The strategy approach allows them to be mixed in any combination. I think the Struts developers with v1.3 are running into these difficulties and it is creating a real problem, if I am not mistaken. c. The same strategy interface can be used in multiple classes. A single use of an expensive instance of a class can be used for multiple objects' state. d. You can test it with mock objects. Jack On Sun, 6 Mar 2005 16:43:48 -0500, Bill Siggelkow <[EMAIL PROTECTED]> wrote: > One thing that I see is that the PopulateActionForm you supplied is > essentially the same as the Abstract one -- that is, it defines the > algorithm in the template -- the difference, of course, being that the > method implementations are delegated to a Helper instead of left up to > a concrete subclass (composition vs inheritance). Still, however, the > methods in Helper must be specified by an interface (which you don't > show). What would be the scope of this helper? Would it something like > an interface named PopulateActionFormHelper with a default impl > provided by Struts or would you propose a more generalized Struts > Helper? Likewise, how do you propose to set the Helper in the > PopulateActionForm -- a plug-in or IoC or something else? Furthermore, > couldn't someone implement this thing pattern anyway by creating their > own subclass of AbstractPopulateActionForm and delegating from their? > After all, the implementation has to belong somewhere. > > On 2005-03-06 14:12:52 -0500, Dakota Jack <[EMAIL PROTECTED]> said: > > > Hi, Joe, > > > > Thanks for the response. > > > > This is what you asked for last time. I assume this means that what I > > provided is not enough to talk about? That sort of surprises me, > > because I thought that showed how you can do the same thing without > > any backward compatibility issues? Didn't it? How does the use of > > Strategy I suggested do anything inconsistent with code that already > > exists? > > > > I guess I don't see where the incompatibility lies. That is why I > > gave the example of an actual class (the popluate class) in the > > present work on the chain supplanting the RequestProcessor. I guess I > > don't understand what you are saying there because there was what I > > thought was a clear showing of how you could use the Strategy pattern, > > avoiding the difficulties of the Template Method pattern, without > > incurring any costs. Didn't the code show that? > > > > If the code did not show that, could you please tell me why? I > > thought that is just what it showed. That is why I gave it to you in > > response to your question. Certainly your question was more than > > legitimate. I just thought I had answered it. If you mean that to > > suggest alternatives I have to code all of Struts rather than suggest > > and show how it could be done to open conversations, then I don't > > understand. I am sure you don't mean that/ > > > > > > > > > > On Sun, 6 Mar 2005 12:30:00 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > >> At 8:36 PM -0800 3/5/05, Dakota Jack wrote: > >>> I gave you a specific, but you did not respond, Joe. Can you tell me why? > >> > >> OK, ready to reply. > >> > >> Basically, we're aiming to release a version of Struts 1.3.0 which is > >> completely backwards compatible with Struts 1.2.x. At this point, > >> the template method works and provides backwards compatibility; > >> furthermore, the nature of the ComposableRequestProcessor is such > >> that people who are ready to press forward with new designs can do so > >> with minimal impact to the released codebase and with whatever level > >> of concern for backwards compatibility is appropriate. > >> > >> In short, if you want to use the Strategy method, please, feel free. > >> If you want to put up some web pages explaining to people how to use > >> it and perhaps providing code, I think that would be very nice. Over > >> time, it may make sense to change the way that the Struts core code > >> works to use the Strategy pattern. Or, it may not. > >> > >> For example, look at Hubert's FormDef project. He had an idea for a > >> different way to use Struts; he put it together and made it available > >> to people. People who are ready to use it can do so. > >> > >> Joe > >> > >> -- > >> Joe Germuska > >> [EMAIL PROTECTED] > >> http://blog.germuska.com > >> "Narrow minds are weapons made for mass destruction" -The Ex > > --------------------------------------------------------------------- > 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]
