From: Robert Klemme Date: 2009-08-13T01:33:05+09:00 Subject: Re: Which initialize method? (or, who is self?) 2009/8/12 Robert Dober : >>> 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. Yes, I think that is an appropriate description. > 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. Another option would be to require a sub class to exhibit this information via methods or constants. Those could be queried as easily as the "constructor" argument but they would be placed where they belong conceptually (in the class). > I believe it is crucial for easy maintainable design, but right now I > am a little bit confused. Yes, the design is not obvious. > 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. Hmm... For me the problem is more in the way how the initialize methods are built. Since algorithm, block_size, output_length are not passed in on the call they must be provided by the sub class (i.e. the implementation of sub class #initialize methods). If they are not somehow derived from the input (which is only "key") or otherwise dynamically generated they could be as well class constants. >>> 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. Documentation would certainly help but I feel a little itch from the design (see above). So it's probably a bit of both. > Thx for your time. You're welcome! I am wondering what Daniel makes of this... Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/