iOS Referencing a child class in a parent class, good or bad?

[SAIRUS]

I'm working some existing code, and noticed the developer had done some references to a child class in a parent. While it is working, I thought this was generally frowned upon.

Is this true? Am I looking at inheritance rules wrong?

 

[Duncan C]

I'm working some existing code, and noticed the developer had done some references to a child class in a parent. While it is working, I thought this was generally frowned upon.

Is this true? Am I looking at inheritance rules wrong?

Bad. Parents are not supposed to know about the specifics of their children.

The other way (children referring to the superclass) is very common.

I guess there might be a special-case design reason to do this, but it would be a rare exception, and there is likely a better, cleaner way to handle it.

Can you be more specific as to what the developer was doing?

 

[SAIRUS]

Sure.

The parent is checking for the class of the child and then calling a method in that child class where logic can be placed to update a subview associated with the parent.

 

[MattInOz]

Sounds like the job of a Delegate.

 

[TheWatchfulOne]

Sure.

The parent is checking for the class of the child and then calling a method in that child class where logic can be placed to update a subview associated with the parent.

It almost sounds like delegation.

Is this before or after the child is pushed onto the navigation stack?

 

[SAIRUS]

I guess you could say both are being together, as the parent class is view controller.

 

[ArtOfWarfare]

Can someone explain class clusters to me? I feel like they might be an example of parent classes that reference their own children.

 

[Duncan C]

Can someone explain class clusters to me? I feel like they might be an example of parent classes that reference their own children.

Well, sort of.

Class clusters are a bit odd.

A class cluster has a public interface that is fixed and fairly simple, and then some number of private subclasses that actually implement that public interface.

Class clusters allow the designer to create a class that can use a variety of different optimizations depending on how they are used at runtime.

Examples of class clusters are NSArray, NSDictionary, and NSString.

Take NSString as a simple example. if you pass in ASII data when you create a string, the system might analyze the data and decide that the internal storage should be purely 8-bit. If, however, you pass in non-roman data across a variety of different Unicode pages, the system might decide to use full-on 16 bit unicode for storage. If you're using a language like Swedish that's mostly Roman characters but with a fair number of accented characters, it might use a scheme like UTF8 internally that works well for MOSTLY roman characters.

Since the only part that's guaranteed is the public interface, the system can do whatever it wants internally at runtime to get the best performance and/or storage efficiency.

Mutable arrays are another good example of a class cluster. Depending on the type of data you put in an array and how you use it, the system might use a linked list, a b-tree, or an array of C pointers to represent the objects in the array. The system can even mutate the underlying object(s) to different private subclasses based on use.

You're right in that with a class cluster, the cluster is aware of the specifics of the private subclasses that it uses.

Normally a parent class doesn't (and shouldn't) know about the specifics of it's subclasses. The parent defines the base behavior, and the subclasses customize or extend that behavior.

 

[TheWatchfulOne]

Can someone explain class clusters to me? I feel like they might be an example of parent classes that reference their own children.

The Class Cluster design pattern involves a generic super class which has many specific sub classes.

NSNumber is one example of a class cluster. It has class methods which will return you various types, such as a boolean, integer, float, etc. For more detailed information, I suggest this document.

SAIRUS, can you be more specific about the code you are working with?

Well, I see now, Duncan C beat me at posting an answer (and no doubt gave a better quality answer at that!) I really should learn to type faster. Maybe.


OK, after re-reading SAIRUS's question I can see where there are two different possible concepts being implied.

When he(she?) talked about Parent and Child I took that to be a reference to views or view controllers. As in, a parent view creates a child view and pushes it onto the navigation stack.

But then he uses the word "inheritance" which is more related to classes and their sub classes.

Two different concepts which can be expressed with similar terminology. SAIRUS, which are you referring to?

 

[ArtOfWarfare]

Thanks for sharing that. It actually sheds a lot of light on some of the things I've wondered about Obj-C.

Now something I'm wondering is whether it's actually necessary for NSArrayI and the like to expose their own class names. It seems to me that, in the interest of hiding implementation details, NSArrayI and the other private subclasses of NSArray should respond to methods as if they were just NSArrays.

IE, NSArrayI should have an implementation that looks like:

- (bool) isMemberOfClass:(Class)aClass
{
    return [super isMemberOfClass:aClass];
}

- (Class)class
{
    return [super class];
}

 

[Duncan C]

Thanks for sharing that. It actually sheds a lot of light on some of the things I've wondered about Obj-C.

Now something I'm wondering is whether it's actually necessary for NSArrayI and the like to expose their own class names. It seems to me that, in the interest of hiding implementation details, NSArrayI and the other private subclasses of NSArray should respond to methods as if they were just NSArrays.

IE, NSArrayI should have an implementation that looks like:

- (bool) isMemberOfClass:(Class)aClass
{
    return [super isMemberOfClass:aClass];
}

- (Class)class
{
    return [super class];
}

Returning wrong info about an object's class would obscure information that somebody might need.

Apple uses a different tack. For class clusters, instead of isMemberOfClass, you're supposed to use isKindOfClass to see if an object is a member of a class or any subclass of that class.

 

[ArtOfWarfare]

Returning wrong info about an object's class would obscure information that somebody might need.

Apple uses a different tack. For class clusters, instead of isMemberOfClass, you're supposed to use isKindOfClass to see if an object is a member of a class or any subclass of that class.

I wonder whether anyone outside of Apple (who would have the source code on hand to debug with) has ever found that to be useful.

Now that I'm aware of this behavior, I feel like taking advantage of it, just to satisfy my curiosity... I'll probably elaborate tonight after I run some experiments on NSArrays.)