Sure, Jeff. Do what you like. I am going to stick with the meaning established for the Template Method pattern in the literature, but if you prefer to develop your own use of the terms, be my guest. You can call rain "snow" if you like without any objection from me too.
If you think of any class which conflates the abstract and concrete classes as an instance of these patterns, then pretty much every class in the action package is an instance and the original discussion about whether CoR should be Strategy or Template Method based is impossible to do. But, go there, if you like, without any problems on my part. You might, however, want to check out this link: http://www.amazon.com/gp/reader/0521529190/ref=sib_dp_pt/002-5991192-8319241#reader-link I don't think, by the way, that a pattern can be either "descriptive" or "prescriptive", but, then, I am not sure how you use those words either. I think that "descriptive" and "prescriptive" apply to language constructs, which patterns in coding definitely are not. But, again, maybe you are just speaking loosely or sort of poetic-like. That is okay with me. Main Entry: de新crip暗ive Pronunciation: di-'skrip-tiv Function: adjective 1 : serving to describe <a descriptive account> 2 a : referring to, constituting, or grounded in matters of observation or experience <the descriptive basis of science> b : factually grounded or informative rather than normative, prescriptive, or emotive <descriptive cultural studies> 3 of a modifier a : expressing the quality, kind, or condition of what is denoted by the modified term <hot in "hot water" is a descriptive adjective> b : NONRESTRICTIVE 4 : of, relating to, or dealing with the structure of a language at a particular time usually with exclusion of historical and comparative data <descriptive linguistics> - de新crip暗ive損y adverb - de新crip暗ive搖ess noun Main Entry: pre新crip暗ive Pronunciation: pri-'skrip-tiv Function: adjective 1 : serving to prescribe <prescriptive rules of usage> 2 : acquired by, founded on, or determined by prescription or by long-standing custom - pre新crip暗ive損y adverb G'day! Jack On Wed, 9 Mar 2005 14:28:37 -0500, Jeff Beal <[EMAIL PROTECTED]> wrote: > 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] > > -- "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]
