From: Robert Dober <robert.dober@...>
Date: 2009-08-12T20:50:00+09:00
Subject: Re: Which initialize method? (or, who is self?)

On Wed, Aug 12, 2009 at 9:25 AM, Robert
Klemme<shortcutter@googlemail.com> wrote:
> 2009/8/12 Robert Dober <robert.dober@gmail.com>:
>> On Tue, Aug 11, 2009 at 10:10 PM, Robert
>> Klemme<shortcutter@googlemail.com> wrote:
>>> On 11.08.2009 21:23, Daniel Waite wrote:
>>
>> Well analyzed, I did not really get it.
>
> Thank you!  It took me some time to see through it, too.
>
>> I ask myself if this is not a violation of one of the principles of OO
>> design?  Base.hexdigest assumes that the implementer of subclasses'
>> new will do the right thing, that is call super( ) with the right
>> params  or implement allocate and send :initialize the right way.
>
> I would say Base#initialize is the one to "assume" something, namely
> that SubClass#initialize invokes it with the proper argument list.
>
>> This is clearly a superclass relying/imposing subclass behavior, not
>> what I learnt.
>
> It is quite common for a base class to impose certain behavior related
> constraints on its subclasses - just think of the template method
> pattern.
I was afraid you would say this ;). So I conclude that you indeed see
it somehow like this I could not make my mind up.
Correct me if I am mistaken but the template pattern is an abstraction
over differently implemented details, and indeed that seems to be the
case here. What still worries me is that the implemented details shine
through, I would rather hide them away. But right now I am confused
about the way I would prefer the responsibilities defined here.
I believe it is crucial for easy maintainable design, but right now I
am a little bit confused.
Probably I do not like the idea of the factory being in the base
class. Maybe because this is too Java like ;). Gotta think that over
again.

>> Well I do not say it must not be done, but at least it
>> merits prominent documentation, so that less inspired folks than you
>> Robert, that is poor OP and me ;), get it too.
>
> I agree: if the original pastie covered the complete code then
> documentation is really lacking some explanation.  Even if class Base
> is just intended for library internal usage, documentation would help
> the maintainer.
It all boils down to documentation I agree.
>
> IIRC in "Java Pitfalls" there is a chapter about how to get
> constructors right in light of inheritance  (Item 8: Design
> Constructors for Extension) .  Unfortunately I do not remember the
> details nor do I have a copy of the book available (too bad it's out
> of print) but the statement which was put forward mandated that
> classes with only default constructors were preferable.  It may have
> to do with the fact that in Java every subclass should then also
> provide constructors with the same argument list as the super class
> constructors and that the number of constructors dramatically
> increases when adding optional properties to the sub class (the # of
> constructors doubles).
Pitty indeed;
>
Thx for your time.
R.
-- 
module Kernel
  alias_method :ë, :lambda
end