From: Robert Klemme Date: 2009-08-12T16:25:46+09:00 Subject: Re: Which initialize method? (or, who is self?) 2009/8/12 Robert Dober : > On Tue, Aug 11, 2009 at 10:10 PM, Robert > Klemme 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. 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 -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/