From: Gavin Sinclair Date: 2003-02-12T01:27:19+09:00 Subject: Re: inheriting from base classes On Wednesday, February 12, 2003, 1:26:50 AM, dblack wrote: > [On ClassRoster < Array] > > But then there's the question: if a ClassRoster is essentially an > ordered list of Student objects, and that list is going to be added > to, sorted, subtracted from, mapped over, etc. etc.... what is the > disadvantage to having it subclass Array (rather than sort of shadow > Array via instance variables and rewriting of methods that Array > already has)? I'm willing to believe there are disadvantages, but > I'm not succeeding in picturing an actual scenario where it would > play out badly. If I were writing code that needed to perform all those operations on class rosters, I would be inclined to do this: class_roster = [] Then you can apply all the Array methods you like! :) But you want some ClassRoster-specific methods. I'd be looking at hiding the complex manipulations of the class roster from the outside world. class ClassRoster def initialise @roster = [] end def foo @roster.manipulate end ... end That's what you should be aiming for in OO code: users don't have to do any low-level stuff on your objects. You implement just the methods they need. They shouldn't have to know that Array is used to implement it. Of course, you need a way of building up a roster. That might be by parsing a text file, or you may need to resort to: class ClassRoster def <<(o) @roster = [] end end Rather than say "gosh, what a pain doing such a boring method", look for ways to eliminate the need for it. Or, if a few such methods are indeed perfectly justifiable, then use one of Ruby's forwarding mechanisms, or try to do more than just delegate (error checking, for instance). At the end of the day, the fewer methods per class, the better. Superfluous methods cloud the intention of the class. (String et al are excluded from this rule for obvious reasons.) Gavin