Question

My situation:

ClassA may or may not have a parent of type ClassB. Therefore saying [instanceOfA.superview somethingClassBSpecific]; is half hazardous. Plus, Xocde will get pissy, for good reason.

Is the recommendation here to dispatch a notification, or do some logic on the superview, e.g.,

if([objectOfA.superview respondsToSelector:somethingClassBSpecific] != nil){
    //...
}

Or create a delegate of type ClassB where the situation permits?

Answer 1

As is so often the case, it depends. Using the view hierarchy, notifications, and delegation are three different ways that objects can communicate with each other. Deciding which of those (if any) is most appropriate requires thinking about how the objects in question are related to each other.

Notifications provide very loose (nearly zero) coupling between objects. They also provide one-to-many communication — you post a notification, and every object that’s listening for that notification will get the message. But notifications aren’t always appropriate; communication is mainly in one direction only, and abusing the notification mechanism can lead to performance problems.

Delegation gives you a way to customize the behavior of an object. The most obvious example is the application delegate. Most every iOS application is based on the same class: UIApplication. UIApplication is exactly the same for every app even though each app does its own thing. The application object uses a delegate to provide the customization that gives the application its unique behavior.

The view hierarchy is another way that (some) objects are connected to each other. If the behavior you’re implementing is a) part of a view and b) dependent on that view’s relationship with other views, then it may make sense to use the superview and subviews properties.

So, what kind of functionality are you trying to implement?