NSNotificationCenter 与设计模式 (Observer)_app

概述龙生九子，设计模式中的“抽象” 在开发中，我们面临各种模块的开发。为了降低模块间的偶合性，我们往往先把模块间的接口抽象出来，以应对高速变化的需求与业务。模块多了，接口也就多了；接口多了，抽象也就多了；抽象多了，我们的系统就不是科学了。。。是玄学（ _ ）嘿嘿。。。所以，这个。。。言归正转，我们系统中所用的“抽象”是基本，“应变简单”才是最终目的。产品修改需求，业务的扩展，只要有良好的龙生九子，设计模式中的“抽象”

在开发中，我们面临各种模块的开发。为了降低模块间的偶合性，我们往往先把模块间的接口抽象出来，以应对高速变化的需求与业务。
模块多了，接口也就多了；
接口多了，抽象也就多了；
抽象多了，我们的系统就不是科学了。。。是玄学（ _ ）
嘿嘿。。。
所以，这个。。。言归正转，我们系统中所用的“抽象”是基本，“应变简单”才是最终目的。
产品修改需求，业务的扩展，只要有良好的接口设计，我们都可以兵来将挡，水来土Ｘ。
系统强大到可以做到从容的：“随机应变，随需而变”。
讲一个龙生九子情景，可以更进一步的了解什么才是抽象：
龙有九个儿子：

排行	名称
老大	囚牛
老二	睚眦（yá·zì）
老三	嘲风（cháofēng）
老四	蒲牢（púláo）
老五	狻猊（suān’ní）
老六	霸下（bā·xià）
老七	狴犴(bì’àn)
老八	负屃（fù xì）
老九	螭吻（chīwěn/chīwěi）

有的会跳，有的会跑，有的会爬，有的会游，有的会飞。
设想有个情景，龙王想让这九个儿子去一个地方，但又不想知道每个儿子的行走方式再逐个通知。
这里就产生两个成本，
其一，是学习各种行走方式的成本，这个问题带来的是龙王与九子的强偶合，这个是我们最不想看到的。
其二，在其一的条件下必须逐个通知的成本。

我们的抽象思想就可以用在这上面，帮助龙王解决上面的小麻烦。
九子行走的方式可以统一抽象为“行动”，只不过九子“行动”的具体实现略有不同而已。
有了这个，九子在这个问题上对龙王的接口就统一了。另外，龙王也没必要去学习具体的实现方式。
现在，只要发送统一的口令：“行动”，九子就会九龙过海各显神通。

“行动”做为接口，弱化了龙王与九子在这个问题上的偶合，并直接降低“其一”的成本。
今天我们要讲的就是“Observer”模式来解决“其二”的成本。

Observer 设计模式

在我们面向对象的开发中，经常会使用到此模式。用“生产者”与“消费者”的典型实现来解偶模块间的偶合度。
此模式的实现，网上找了两图，以做示例：

上面我们看到的图分两部分，左边是消息的生产者（发送），左边是消息的消费者（接收者）。
其中“气象站”扮演了相当重要的角色，由它管理消息的生产者与消费者。
也正是因为它的存在，使左右两个模块实现解偶。

气象站做了什么

1，收集气象信息
这些感应装置，不定期的把不同的气象数据推送给气象站。
这些数据我们就可以理解为消息，而制造这些消息的感应装置，我们称之为消息的生产者。

2，分发气象信息，
把从感应器中发送过来的信息分发给不同的接收者。
像，有些客户只在乎气温信息，它只需要在气象站注册为一个“气温”的“监听者”，当气温信息从“温度感应装置”发送给“气象站”时，它就会把这个信息转发给关心气温的用户。
这里有一个很巧妙的细节：
“温度感应装置”只负责收集气温变化的信息，并把信息发送出去，其不知道的是谁在关心这些数据，也不知有多少“监听者”，更不知道这些气温的“监听者”拿这些数据来做什么。这就是模块“单一职责”的设计铁则，让类的功能尽可能的单一。
相对应的，这些对气温的“监听者”，对消息的来源并不关心，或并不知情，只知道怎么把气温的消息展示给用户。

Objective-C中的Observer模式实现

在我们的iOS开发中，很幸运，Cocoa架构中已经提供了消息中心组件来实现Observer模式。

NSNotificationCenter

NSNotificationCenter 是 Cococa消息中心，统一管理单进程内不同线程的消息通迅，其职责只有两个：

1，提供“观查者们”对感兴趣消息的监听注册

[[NSNotificationCenter defaultCenter] addobserver:self selector: @selector (printname:) name: @ "messagename" object:nil];

a,defaultCenter，消息中心只有一个，通过类方法获取它的单例。
b,addobserver，添加监听者实例，此处为当前实例
c,selector，observer中的一个方法指针，当有消息的时候会执行此方法，并把相关上下文以参数传递过去
d,name，注册所关心消息的名称，
e,object，这个是对消息发送方的一个过滤，此参数据说明当前监听器仅对某个对象发出的消息感兴趣。

整体意思：
向消息中心中注册一个“监听者”（当前实例self,相当于Java里的this）。当有名为NSWindowDIDBecomeMainNotification 的消息发送到消息中心时，执行本实例的aWindowBecameMain方法。

2，接收“消息”，并把消息发送给关心它的“观查者们”。
消息的推送:

postNotificationname:@"messagename"object:niluserInfo:[NSDictionary dictionaryWithObject:@"jory" forKey:@"name"|^Archive.zip]];

a,postNotificationname，推送消息的名称，匹配在注册消息监听者时的消息名称。
b,object,发送消息的实例
c,userInfo，发送消息时附带的消息上下文，此实例为一个字典实例（相当于Java里的HashMap）。

3，当有消息推送到消息中心后，会把此消息发送给相关的“监听者”，并会执行消息注册时的方法：

-(voID)printname:(ID)sender{ Nsstring *name = [[sender userInfo] objectForKey:@];NSLog(@"name: %@",name);}

方法很简单，从消息上下文中(发送消息时的 userInfo)，获取"name"并打印。

以下是一个完整的消息分发工程，
特意把事件注册与推送写到两个类中（从头文件中可以发现两个类并没有直接的引用）

项目：Archive.zip

主要代码如下
notificationTestAppDelegate中：

@H_949_301@//在消息中心中注册消息 [[NSNotificationCenter defaultCenter] addobserver:self(clickBtn:)name:@"clickBtn"object:nil];

TestVIEw中：