Re: Subclassing with more restrictive initializers
Re: Subclassing with more restrictive initializers
- Subject: Re: Subclassing with more restrictive initializers
- From: Quincey Morris <email@hidden>
- Date: Wed, 25 Feb 2009 10:38:55 -0800
On Feb 25, 2009, at 08:39, Andy Klepack wrote:
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.
Also see:
http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/chapter_4_section_4.html#/
/apple_ref/doc/uid/TP30001163-CH22-SW5
which sort of contains an answer to your question:
"A class must also make sure that all inherited initialization methods
work. For example, if class A defines an init method and its subclass
B defines an initWithName: method ..., B must also make sure that an
init message successfully initializes B instances. The easiest way to
do that is to replace the inherited init method with a version that
invokes initWithName: ... Covering inherited initialization methods
makes the class you define more portable to other applications. If you
leave an inherited method uncovered, someone else may use it to
produce incorrectly initialized instances of your class."
In practice, though, I agree with Michael that leaving superclass
initializers "uncovered" is not a big problem, unless it exposes some
kind of security exploit.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden