velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <>
Subject Re: ResourceLoader.init() question
Date Sun, 06 Jan 2002 13:10:46 GMT
On 1/6/02 1:30 AM, "James Maes" <> wrote:

> #define ckeleton skeleton
> #define programer programmer

Ew.  How about



> okay, I'm done....
> On Sunday 06 January 2002 12:27 am, James Maes wrote:
>> Class Behavioral - Template Method
>> Intent - "Define the ckeleton of an algorithm in an operation, deferring
>> some steps to subclasses.  Templates Method lets subclassess redefine
>> certain steps of an algorithm without changing the algorithm's structure."
>> - James "Bored programer with a copy of Design Patterns in front of me"
>> Maes
>> On Sunday 06 January 2002 12:13 am, Donnie Hale wrote:
>>> The "template method pattern" doesn't have anything to do with
>>> "templates" as in C++ or "generics" as in JDK 1.4/5. It's the name of a
>>> pattern from the "Gang of 4" Design Patterns book. I don't have my copy
>>> in front of me right now to provide the "official" motivation and
>>> application of the pattern, but, in short, it establishes a non-virtual
>>> public interface through a base class whose implementation is a
>>> "template" which can/must be overridden by derived classes.
>>> As far as protected member variables in a base class goes, Geir's last
>>> message summed it up most concisely: it violates encapsulation.
>>> While the books aren't Java-specific, the rules in Scott Meyers'
>>> "Effective C++" and "More Effective C++" are highly applicable.
>>> Donnie
>>>> -----Original Message-----
>>>> From: Nick Bauman []
>>>> Sent: Saturday, January 05, 2002 10:38 PM
>>>> To:
>>>> Subject: RE: ResourceLoader.init() question
>>>> Donnie said:
>>>> [edit]
>>>>> If one subscribes to the Liskov substitution principal (a derived
>>>>> class should be able to be used wherever a base class is used w/o the
>>>>> user having to know which it is), then more up-front attention needs
>>>>> paid on two fronts: 1) what is the full contract of a base class? 2)
>>>>> does a derived class really meet the "is-a" test?
>>>>> I'm a huge fan of the template method pattern, and I think it's wider
>>>>> use in base classes would help enormously. As regards this question,
>>>>> it would help because the base class would be enforcing the state
>>>>> machine, if you will, through which its implementation progresses. It
>>>>> could then very easily pass what might otherwise be a protected
>>>>> member variable to an abstract template method for derived class use.
>>>> Templates aside for a moment and I generally agree (because I think
>>>> they're good too), this is Java: we use interfaces to establish
>>>> contracts.
>>>> Liskov substitution principal is what the Java interface is all about.
>>>> Without interfaces, implementations end up pushing more and more
>>>> functionality up the heirarchy tree into what become abstract God
>>>> classes.
>>>> Yeech. While it's true that "nobody looks at what's in the base classes
>>>> enough" (how many times have I seen people rewrite stuff that's
>>>> already in
>>>> the base class they weren't paying attention to!), this doesn't
>>>> negate the
>>>> value of protected members. Again, Templates aside, sometimes things
>>>> are simply correctly factored by using protected member variables in a
>>>> base class.
>>>> --
>>>> Nick Bauman
>>>> Cortexity Development
>>>> --
>>>> To unsubscribe, e-mail:
>>>> <>
>>>> For additional commands, e-mail:
>>>> <>

Geir Magnusson Jr.                           
System and Software Consulting
Be a giant.  Take giant steps.  Do giant things...

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message