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 > 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~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
