Accidentally replied to only Jack.
---------- Forwarded message ---------- From: Jeff Beal <[EMAIL PROTECTED]> Date: Wed, 9 Mar 2005 14:23:35 -0500 Subject: Re: Why Template Method instead of Strategy in Commons Chain? To: Dakota Jack <[EMAIL PROTECTED]> Hey, thanks for the reply. I did go out and do a bit of homework on my own in the interim, and based on what you had written earlier, I figured that the missing abstract class was the "big difference" between the Struts RequestProcessor and the "Template Method Pattern". In my understanding, things like Patterns and UML models are descriptive, not prescriptive. They give us developers a common framework to discuss things without being bogged down with the details of code. Particularly when discussing among developers with different linguistic (as in programming language) backgrounds, they provide a very useful common ground. They are, in my mind, abstractions. As such, I find it perfectly valid to describe the Struts RequestProcessor as following the Template Method Pattern, only the Abstract Class and the Implementing SubClass are the same concrete Java class. If you disagree with me on that, that's fine. I could honestly care less about whether we call the RequestProcessor a Template Method pattern or not. It is what it is and that's all it is, or, to quote Shakespeare, "a rose by any other name would smell as sweet." Thanks for clarifying your standpoint for me, though, and keep up the good work! (By 'good work' I do mean riling up the entire Struts development team on a frequent basis. It's fun to watch.) -- Jeff On Wed, 9 Mar 2005 10:36:44 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote: > Hi, Jeff, > > I am going to say some really intelligent things here, so listen up. ///;-) > > > The Template Method, not "Template" merely, pattern is really clear, > well understood, a matter of public record, and not really a subject > of debate. What I think is really irrelevant. > > The RequestProcessor is just a class with three central methods, and > one of the methods is huge so that it is broken into sensible parts to > make it more manageable and readable. There is no "pattern" to the > class. > > I don't know, in fact, if a single class can have a pattern. I think > that most, if not all, of the patterns only make sense in combination > with other classes. > > Even if, for example, you know how to code an interface, which is > pretty damned easy right at the "get go", that does not mean you > understand at all how interfaces work, which actually is pretty damned > hard at first. The interface pattern can only be understood by having > another class access concrete classes through the interface. Then and > only then does the meaning or point of the interface pattern become > clear. To say that an interface alone is an instance of the Interface > pattern would be really strange and not much help. > > There are different sorts of patterns. They have been categorized in > various ways in various places: "creational", "behavioral", > "structural", etc. The Template Method is one of the "behavioral" > patterns along with Chain of Responsibility, Comand, Mediator, > Observer, Strategy, Visitor, etc. To write code the exemplifies the > Template Method you have to do the following: > > 1. Write an abstract class that contains only part of the logic > needed to accomplish its purpose. > > 2. Organize this class so that its concrete methods call an abstract > method where the missing logic would have appeared. > > 3. Provide the missing logic in subclass methods that override the > abstract methods. > > So, you CANNOT change the RequestProcessor class so that it is an > instance of the Template Method pattern. You could make it a concrete > class in a Template Method pattern by providing a distinct super class > that has process(...) as a concrete method and the other eighteen > methods in the process class as abstract methods and doing something > else. You have to do something else, however, and HERE IS THE HARD > PART THAT PEOPLE SEEM TO MISS. You need to make both the abstract > class and the concrete class important in your application. If you > have an abstract class as stated and you make the RequestProcessor > implement the abstract methods, this is NOT a Template Method pattern > if the abstract class is not important to the application. Similarly, > if you just make interfaces for classes without a real use for the > interface in your application you get the lyrics but miss the tune. > > Consequently, not only does there have to BE an abstract class to have > Template Method but you have to USE the abstract class. To say that > the RequestProcessor class is an example of the Template Method is > actually fundamentally mistaken about the nature of patterns, their > importance, their use, and how we have to understand them. > > But, then, that is just my opinion. ///;-0 > > > Jack > > > On Wed, 9 Mar 2005 12:01:59 -0500, Jeff Beal <[EMAIL PROTECTED]> wrote: > > Here I go, exposing my ignorance of patterns. (No, I have not read > > the "Gang of Four" book on patterns or any other such scriptural > > reference.) > > > > Jack -- > > > > Exactly what would have to change in the current RequestProcessor for > > you to consider it a "Template" pattern? > > > > -- Jeff > > > > > > On Wed, 9 Mar 2005 06:41:23 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote: > > > TEMPLATE! METHOD! TEMPLATE! METHOD! TEMPLATE METHOD! Scheesch! Help! > > > > > > The RequestProcessor is NOT difficult to understand. It is a java > > > CLASS, neither an abstract class nor an interface, which has one > > > principal public method, viz. process(...) which involves a lot of > > > code which is further broken down into parts delivered seriatim by > > > eighteen protected methods. There are also three protected supporting > > > methods and two public methods for initialization (init(...)) and > > > destruction (destroy()). The "structure" of the class, with the > > > processing in the process(...) method is "shown" below. > > > > -- > > Jeff Beal > > Webmedx, Inc. > > Pittsburgh, PA USA > > > > -- > "You can lead a horse to water but you cannot make it float on its back." > ~Dakota Jack~ > -- Jeff Beal Webmedx, Inc. Pittsburgh, PA USA -- Jeff Beal Webmedx, Inc. Pittsburgh, PA USA --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
