scenario

callBack: block, delegate
trigger event:

Block

  • con: hard to track?

  • Features

    • danger of creating retain cycles.

      If the sender needs to retain the block and cannot guarantee that this reference will be a nilled out, then every reference to self from within the block becomes a potential retain cycle.

    • very good fit if a message we call has to send back a one-time-use response that is specific to this method call,

      because then we can break potential retain cycles. Additionally, if it helps readability to have the code processing the message together with the message call, it’s hard to argue against the use of blocks. Along these lines, a very common use case of blocks are completion handlers, error handlers, and the like.

Delegate

Definition, normally one-to-one

Delegation is a widespread pattern throughout Apple’s frameworks. It allows us to customize an object’s behavior and to be notified about certain events.

  • Features

    • sender needs to know receiver (through the delegate), but not the other way around.
    • coupling is loosened, sender only knows that its delegate conforms to a certain protocol.
    • delegate protocol can define arbitrary methods, we can model the communication based on needs.
    • delegate(receiver) can send payloads in arguments to the sender, such as a block
    • delegate(receiver) can get respond as return value from sender

  • danger of overusing the delegation pattern

    • If two objects are that tightly coupled to each other that one cannot function without the other, there’s no need to define a delegate protocol.
    • In these cases, the objects can know of the other’s type and talk to each other directly. Two modern examples of this are UICollectionViewLayout and NSURLSessionConfiguration.

Notification

  • one obj to many obj

  • Features:

    • decoupling class, sender/receiver don't need to know each other
    • can take payload
    • one way, cannot reply

  • con:

    • hard to test：必须保持通知名一致，但写错了也不会报错
    • hard to use，一般查看.h文件看有什么方法可以调用，而通知实在.m中实现
    • if forget remove observer，app will crash (only for Objective C)
Description

Notifications are a very good tool to broadcast messages between relatively unrelated parts of your code, especially if the messages are more informative in kind and you don’t necessarily expect anyone to do something with them.

Notifications can be used to send arbitrary messages and they can even contain a payload in form of their userInfo dictionary or by subclassing NSNotification. What makes notifications unique is that the sender and the recipient don’t have to know each other. They can be used to send information between very loosely coupled modules. Therefore, the communication is one-way – you cannot reply to a notification.

KVO: Key Value Observing

KVC: Key Value Coding -
KVO: Key Value Observing - listen object properties change

  • Features

    • receiver get notification by sender's value change
    • receiver need to know the lifespan of the sender. receiver has to unregister the observer before deinit the sender
    • one sender to many receiver

  • In swfit 在 Swift 中我们也是可以使用 KVO 的，但是仅限于在 NSObject 的子类中。这是可以理解的，因为 KVO 是基于 KVC (Key-Value Coding) 以及动态派发技术实现的，而这些东西都是 Objective-C 运行时的概念。另外由于 Swift 为了效率，默认禁用了动态派发，因此想用 Swift 来实现 KVO，我们还需要做额外的工作，那就是将想要观测的对象标记为 dynamic。

Definition:

KVO is a mechanism to notify objects about property changes. It is implemented in Foundation and many frameworks built on top of Foundation rely on it. To read more about best practices and examples of how to use KVO, please read Daniel’s KVO and KVC article in this issue.
Daniel's KVO an KVC article

KVO is a viable communication pattern if you’re only interested in changed values of another object. Requirement:
  • the recipient, an object that will receive the messages about changes has to know about the sender, an object with values that are changed.
  • the recipient also needs to know about the lifespan of the sender, because it has to unregister the observer before the sender object gets deallocated.
  • If all these requirements are met, the communication can even be one-to-many, since multiple observers can register for updates from the object in question.

Target-Action

  • Def:

    • the typical pattern used to send messages in response to user-interface events. Both UIControl on iOS and NSControl/NSCell on the Mac have support for this pattern.

    • establishes a very loose coupling between the sender and the receiver of the message. The receiver of the message doesn’t know about the sender, and even the sender doesn’t have to know up front what the receiver will be.

    • In case the target is nil, the action will travel up the responder chain until it finds an object that responds to it. On iOS, each control can even be associated with multiple target-action pairs.

  • limitation

    • the messages sent cannot carry any custom payloads.

      On the Mac action methods always receive the sender as first argument. On iOS they optionally receive the sender and the event that triggered the action as arguments. But beyond that, there is no way to have a control send other objects with the action message.

(KVO/Block/Delegate/Notication/Target-Action)[https://www.objc.io/issues/7-foundation/communication-patterns/]
(CHN version)[http://www.jianshu.com/p/916d0ed51ce6]

How to select pattern ?

results matching ""

    No results matching ""