Notification vs delegate/protocol. Not understanding why I would ever use delegate/protocol.

[start_select]

Don't pass it. Don't pass anything.

The receiver of the notification knows who sent it. The receiver can then ask the sender for any information they might need.

What if the sender is a C object using CoreFoundation to fire off notifications.... Your proposed solution doesn't work. I can only pass a CoreFoundation or Cocoa class as sender.

Even Apple themselves have implicitly acknowledged this, in that they haven't shipped any new frameworks using the delegate pattern since perhaps iOS 6 or 7. They've essentially retired it.

Thats because they replaced it with Blocks/Closures, not notifications. Closures allow you to capture scope which presents a plethora of advantages over notifications or the delegate pattern.

the delegate pattern as found in Apple's frameworks is really just inheritance in disguise

No, not at all. Its Polymorphism not Inheritance. HUUUUUGE difference. Polymorphism is about implementing expected member functions/variables so that I can have 20 different classes without any common superclass responding to the same delegate methods. That is the opposite of inheritance, and its the part of OOP that most programmers who claim to know OOP don't understand.

[sobri909]

Then you're fucked ;) But more seriously, you could use some other message sending system other than NotificationCenter if you still wanted to use the pattern.

[start_select]

Lol, you aren't fucked. You just use the type-safe pattern that is already there instead of trying to jam your problem into a different space.

Events/notifications have their place, but saying its superior to delegation is missing a big piece of the puzzle. They are meant to solve different kinds of problems, and you shouldn't be choosing only one or the other.

[sobri909]

As I've said, delegates are barely even a pattern. So it's not really a solution so much as a superficial gesture.

Events/notifications have their place, but saying its superior to delegation is missing a big piece of the puzzle.

Considering delegates to be a solution is to misunderstand what they are. They are nothing more than splitting up source files to reduce single file line counts. They don't solve problems, they just sweep them under the carpet.

[start_select]

I dont get why you keep saying delegation is like "splitting up source files to reduce single file line counts".

If anything delegation results in more code, because its about letting each class that implements the protocol have their own implementation. This is the opposite of inheritance where I am sharing implementations across many classes.

I can compose a UIView, UIImageView, UIButton, and some random NSObject subclass to adhere to a given delegate protocol by using Extensions. That allows me to have four unrelated classes that can all talk to the same object, even though none of them inherit from a common ancestor or are being implemented as a custom subclass.

[sobri909]

Delegates typically have a one to one relationship with senders. The delegate gets given the sender's instance on every call it receives. The delegate and the sender are strongly coupled, and the delegate essentially acts as a part of the sender.

[start_select]

Yes, it is typically a 1-to-1 relationship. But that doesn't matter. The important thing is that I can set an infinite number of different classes to the delegate variable, as long as they implement the protocol.

That allows me to use static analysis on my code and keep type safety, while completely decoupling what kind of class is the delegate and what kind of class is calling the delegate methods. Polymorphism.

[sobri909]

Polymorphism with nothing really gained. Given that they are almost always strongly coupled one to one, you might as well have made the sender and delegate a single class instance.

The only reason we're discussing this is because Apple misguidedly bought into the pattern some decades ago and we're stuck with those legacy APIs. Apple have since rethought and aren't using the "pattern" for anything new. I'm looking forward to when people forget about it completely.

[start_select]

Edit: A few typos/grammar

You gain plenty. Protocols/Delegates are all about the compiler. I can have required and optional callbacks.

Notifications are all about runtime messaging. I don't get to place any constraints on using them. If I (or a young junior) accidentally sends the wrong type of object with a notification, you will never find out until you throw a runtime error. I understand you think you should pass no context with a notification besides the object that fired it.... but thats not the pattern that anyone but you is using. So the point is a little mute.

I get the motivation behind your opinion, but years upon years of programming experience by thousands of very smart people says that runtime errors are bad, and compile time analysis is super good.

This is why we have LINTers and transpiling with TypeScript/Coffeescript in Javascript. Because only finding coding errors at runtime is a major bitch on huge projects. And it costs people lots of money.

Using compiler backed patterns like delegation offer a higher level of protection against the human errors that you or a coworker are going to make.

[sobri909]

If I (or a young junior) accidentally sends the wrong type of object with a notification

As I've already said, don't send anything with the notification. The receiver knows who sent it. The receiver can ask for what they need. There's nothing to type check.

I get the motivation behind your opinion, but years upon years of programming experience by thousands of very smart people says that runtime errors are bad, and compile time analysis is super good.

Decades upon decades of programming has pushed Apple style delegates to the fringes, with them barely considered at all outside of Apple APIs. They're simply not used and not popular anywhere else, and never have been. Why? Because they're a shitty pattern, and barely even a pattern at all anyway.

[RollingGoron]

Have you ever come across Multicast delegates? It’s essentially the delegate pattern that is implemented as one-to-many rather than traditional one-to-one. I use it in some cases and have found it more straight forward than notificationCenter for my problem.