I've run up against this situation more than once and I'd be interested in any opinions and best-practices out there.
I have a class that has one or more initializers that accept parameters. The class also has behavior. I want to implement a second class that has the behavior of the first in addition to its own behavior. This class should also have more restrictive initializers. That is, the second class should not allow the kind of parameterization that the first class does. On the one hand this feel a like inheritance: the second class really is-a kind of the first class. But those pesky initializers (from the first class) don't make sense for the subclass. On the other hand, this looks kinda like trying to create an instance through sub-classing (and that would be wrong) except that behavior is being added as well. On the other-other hand this feel like it could be composition (instances of the second class have-a member of the first class), but the behavior of the first class would have to be accessed through a wrapper provided by the second class. To make things more concrete (this isn't the actual case I've run into, but it's a similar, simpler illustration) consider a class "File" that has an initializer 'initWithPath:' and behavior 'delete', 'rename', etc. Then consider wanting to implement a class like 'PreferenceFile' that should only refer to files in the Preferences directory and thus has an 'initWithName:" initializer. "initWithPath" provides too much parameterization since it could refer to any file outside of the Preferences directory. Finally, the PreferenceFile class should have the same behavior as File and add some of its own (e.g. "setPrefValue:ForKey:"). Should PreferenceFile inherit from File despite the initialize behavior being undesirable? Is composition somehow more appropriate? Is this confusion the result of thinking about the problem from the wrong direction? Any advice about how to think about and approach this sort of design problem would be great. -Andy _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
