views:

47

answers:

2

As an example, when I'm using an NSMutableDictionary, I know it inherits all the methods of NSDictionary, but how can I know/trust that it has overridden the behavior of those methods if I want to use NSDictionary methods (such as +dictionaryWithObjectsAndKeys) to create my mutable dictionary instance?

More generally, is it the Framework's responsibility to make sure subclasses don't blindly inherit methods that can potentially break instances of the subclass if used? Or is it the coder's responsibility to know not to use them? If Square inherits from Rectangle, and via inheritance I can call

Square *newSquare = [[Square alloc] init];
[newSquare setWidth:3 andHeight:6]; //instead of -(void)setSide:(int)side

I've "broken" the square and other methods which depend on width being equal to height will not work now. What are the rules of the game?

A: 

The rule would be only expose what you would allow to be override it means, put on your interface what is really public. When necessary explicitly state that when overriding an specific method call at some point [super methodName].

On your example you would override the method - (void)setWidth:(int)width andHeight:(int)height, and you would like to throw an error if width != height. Or you could also throw an error and force the user to only use - (void)setSide:(int)side.

For example you could do:

// If you want to test and accept cases when width == height
- (void)setWidth:(int)width andHeight:(int)height {
    NSAssert(width == height, NSLocalizedString(@"This is a Square. Width has to be height.", nil));

    [super setWidth:width andHeight:height];

    // Or

    [self setSide:width];
}

// Or if you want to completely prohibit the usage of the method
- (void)setWidth:(int)width andHeight:(int)height {
    NSAssert(NO, NSLocalizedString(@"This is a Square! Please use - (void)setSide:(int)side method.", nil));
}

If you would like to throw some errors and warnings at compilation time, you could use on the declaration of your methods, some of the macros defined on NSObjCRuntime.h.

vfn
Thanks for the answer; if I may ask for a clarification, this principle is simple to follow when I am implementing my own subclasses. I am still a bit confused, however, as to what/where (docs/headers?) the rules are for Foundation classes. In my example for NSMutableDictionary, I know the methods from the NSDictionaryCreation category are inherited by NSMutableDictionary, but does that imply that the NSDictionaryCreation category methods should be considered "public" and safe for use with NSMutableDictionary? Since I'm not the creator of these classes, I am trepidatious.
snackdefend
This is an issue that we need to live with, since we don't have access to the implementation of some classes we can only assume that they implement/respect all their superclasses or they would throw an error saying that the requested method is not supported.
vfn
Thanks again. It just feels uncomfortable for me to operate in this way coming from open implementation languages. So to rephrase your answer, perhaps I could say "always test your inherited Foundation code"? :)
snackdefend
Or be sure to read the documentation before subclass....otherwise, fill a bug report :)
vfn
A: 

I wouldn't trust the parent convenience method to call your inheriting init method. For example, that dictionary method could be defined as:

+ (id)dictionaryWithObjectsAndKeys:...
{
    return [[[NSDictionary alloc] initWithObjectsAndKeys:...] autorelease];
}

If that method is defined that way then it won't be even be aware of your implementation.

You'd have to create your own convenience method. Something like would be in your MyDictionary implementation:

+ (id)myDictionaryWithObjectsAndKeys:...
{
    return [[[MyDictionary alloc] initWithObjectsAndKeys:...] autorelease];
}

--

Also...

You probably should inherit Rectangle from Square. Inheritance is additive. You can describe Square with one size (width), but for Rectangle you have two sizes (width, height).

No one in particular
I appreciate the answer, but I'm confused and uncertain as to how an NSDictionary method could call an NSMutableDictionary method in that way (wrong direction for inheritance, right?). I've also edited my initial question to specify that I'm not implementing a mutable dictionary class, I'm actually wondering if it's safe to, for instance, use NSDictionary's methods from the NSDictionaryCreation category on an instance of NSMutableDictionary. Similarly, for NSMutableFoo (arrays, strings, etc), which inherit from the immutable class, is everything inherited 'public' to the mutable subclasses?
snackdefend
Oops. I changed the examples a bit to remove the Mutable stuff. The fingers have a mind of their own. ... In terms of being safe - no. A quick test would be to try NSMutableDictionary *md = [NSMutableDictionary dictionary]; NSLog(@"class: %@", NSStringFromClass([md class])); The answer: the non-mutable dictionary.
No one in particular
However, NSMutableDictionary *md = [NSMutableDictionary dictionary]; if ([md isKindOfClass:[NSMutableDictionary class]] Does log, so are these checks are done solely from pointer type checking during runtime (which reflects my lack of understanding of introspection mechanisms, since I'd think one could equivalently check during compile time for non-id things)? I thought NSStringFromClass() just shows internal implementation details that the dictionary class cluster relies upon for use.
snackdefend