Re: Which initialize method? (or, who is self?)

2009/8/12 Robert Dober <[e-mail]>:
> On Tue, Aug 11, 2009 at 10:10 PM, Robert
> Klemme<[e-mail]> 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? =A0Base.hexdigest assumes that the implementer of subclasses'
> new will do the right thing, that is call super( ) with the right
> params =A0or 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.  Every abstract method forces subclasses to implement it,
which need to be instantiated.  Every other method that you want to
override in a subclass has particular arguments that the overriding
method in the subclass is usually bound to (technically not in Ruby,
but even there it is probably a good idea to stick with the argument
list if you want to use the sub class in places where the super class
was used).

> 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.

> Maybe this shows better what I mean
> http://pastie.org/580961

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).

At the moment I can think of only one restriction to this rule of
thumb: immutable classes, mandatory arguments and immutable arguments
for which you do not want to provide a setter.  In both cases it does
make sense to provide the data via constructor arguments, because then
you can ensure that all instances are created properly by raising an
exception in case  wrong data was passed in.

Kind regards

robert

--=20
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/