Example please?
Say you've got a class Foo whose instances needs to do something when the app enters/leaves the background. So you add enterBackground and leaveBackground methods to Foo. Those need to be called from the appropriate app delegate methods.
But the Foo instances spread around your app are members of other classes that are themselves members of other classes. In order to call Foo's enterBackground and leaveBackground methods, all of those parent classes need to have enterBackground and leaveBackground methods which are called by their parents and which call their children. If you add a Foo somewhere new, you have to add "plumbing" through all of its parent classes to the top of your object hierarchy so that its enterBackground and leaveBackground methods can be called.
It's better not to do this, and to find some other way of connecting the Foo instances to the events. The NotificationCenter is an example of another way. It is not without its problems though; for example, unit testing is more difficult when a class has "back door" interfaces such as listening to global notifications.
Topic:
UI Frameworks
SubTopic:
UIKit
Tags: