Ⅰ 什么是观察者模式`
观察者（Observer）模式又名发布-订阅（Publish/Subscribe）模式。GOF给观察者模式如下定义：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
在这里先讲一下面向对象设计的一个重要原则——单一职责原则。因此系统的每个对象应该将重点放在问题域中的离散抽象上。因此理想的情况下，一个对象只做一件事情。这样在开发中也就带来了诸多的好处：提供了重用性和维护性，也是进行重构的良好的基础。
因此几乎所有的设计模式都是基于这个基本的设计原则来的。观察者模式的起源我觉得应该是在GUI和业务数据的处理上，因为现在绝大多数讲解观察者模式的例子都是这一题材。但是观察者模式的应用决不仅限于此一方面。
下面我们就来看看观察者模式的组成部分。
1) 抽象目标角色（Subject）：目标角色知道它的观察者，可以有任意多个观察者观察同一个目标。并且提供注册和删除观察者对象的接口。目标角色往往由抽象类或者接口来实现。
2) 抽象观察者角色（Observer）：为那些在目标发生改变时需要获得通知的对象定义一个更新接口。抽象观察者角色主要由抽象类或者接口来实现。
3) 具体目标角色（Concrete Subject）：将有关状态存入各个Concrete Observer对象。当它的状态发生改变时, 向它的各个观察者发出通知。
4) 具体观察者角色（Concrete Observer）：存储有关状态，这些状态应与目标的状态保持一致。实现Observer的更新接口以使自身状态与目标的状态保持一致。在本角色内也可以维护一个指向Concrete Subject对象的引用。
Ⅱ 在ios中观察者模式和控制中心在什么时候使用
什么是观察者模式？我们先打个比方，这就像你订报纸。比如你想知道美国最近放生了些新闻，你可能会订阅一份美国周刊，然后一旦美国有了新的故事，美国周刊就发一刊，并邮寄给你，当你收到这份报刊，然后你就能够了解美国最新的动态。其实这就是观察者模式，A对B的变化感兴趣，就注册为B的观察者，当B发生变化时通知A，告知B发生了变化。这是一种非常典型的观察者的用法，我把这种使用方法叫做经典观察者模式。当然与之相对的还有另外一种观察者模式——广义观察者模式。
从经典的角度看，观察者模式是一种通知变化的模式，一般认为只在对象发生变化感兴趣的场合有用。主题对象知道有观察者存在，设置会维护观察者的一个队列；而从广义的角度看，观察者模式是中传递变化数据的模式，需要查看对象属性时就会使用的一种模式，主题对象不知道观察者的存在，更像是围观者。需要知道主题对象的状态，所以即使在主题对象没有发生改变的时候，观察者也可能会去访问主题对象。换句话说广义观察者模式，是在不同的对象之间传递数据的一种模式。
观察者模式应当是在面向对象编程中被大规模使用的设计模式之一。从方法论的角度出发，传统的认知论认为，世界是由对象组成的，我们通过不停的观察和了解就能够了解对象的本质。整个人类的认知模型就是建立在“观察”这种行为之上的。我们通过不停与世界中的其他对象交互，并观察之来了解这个世界。同样，在程序的世界中，我们构建的每一个实例，也是通过不不停的与其他对象交互（查看其他对象的状态，或者改变其他对象的状态），并通过观察其他实例的变化并作出响应，以来完成功能。这也就是，为什么会把观察模式单独提出来，做一个专门的剖析的原因——在我看来他是很多其他设计模式的基础模式，并且是编程中极其重要的一种设计模式。
经典观察者模式
经典观察者模式被认为是对象的行为模式，又叫发布-订阅(Publish/Subscribe)模式、模型-视图(Model/View)模式、源-监听器(Source/Listener)模式或从属者(Dependents)模式。经典观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生变化时，会通知所有观察者对象，使它们能够自动更新自己或者做出相应的一些动作。在文章一开始举的例子就是典型观察者模式的应用。
而在IOS开发中我们可能会接触到的经典观察者模式的实现方式，有这么几种：NSNotificationCenter、KVO、Delegate等
感知通知方式
在经典观察者模式中，因为观察者感知到主题对象变化方式的不同，又分为推模型和拉模型两种方式。
推模型
ios desing pattern observer 1
主题对象向观察者推送主题的详细信息，不管观察者是否需要，推送的信息通常是主题对象的全部或者部分数据。推模型实现了观察者和主题对象的解耦，两者之间没有过度的依赖关系。但是推模型每次都会以广播的方式，向所有观察者发送通知。所有观察者被动的接受通知。当通知的内容过多时，多个观察者同时接收，可能会对网络、内存（有些时候还会涉及IO）有较大影响。
在IOS中典型的推模型实现方式为NSNotificationCenter和KVO。
NSNotificationCenter
NSnotificationCenter是一种典型的有调度中心的观察者模式实现方式。以NSNotificationCenter为中心，观察者往Center中注册对某个主题对象的变化感兴趣，主题对象通过NSNotificationCenter进行变化广播。这种模型就是文章开始发布订阅报纸在OC中的一种类似实现。所有的观察和监听行为都向同一个中心注册，所有对象的变化也都通过同一个中心向外广播。
SNotificationCenter就像一个枢纽一样，处在整个观察者模式的核心位置，调度着消息在观察者和监听者之间传递。
ios desing pattern observer 2
一次完整的观察过程如上图所示。整个过程中，关键的类有这么几个（介绍顺序按照完成顺序）：
观察者Observer，一般继承自NSObject，通过NSNotificationCenter的addObserver:selector:name:object接口来注册对某一类型通知感兴趣.在注册时候一定要注意，NSNotificationCenter不会对观察者进行引用计数+1的操作，我们在程序中释放观察者的时候，一定要去报从center中将其注销了。
- (void) handleMessage:(NSNotification*)nc{
//解析消息内容
NSDictionary* userInfo = [nc userInfo];
}
- (void) commonInit
{
//注册观察者
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(handleMessage:) name:kDZTestNotificatonMessage object:nil];
}
通知中心NSNotificationCenter，通知的枢纽。
主题对象，被观察的对象，通过postNotificationName:object:userInfo:发送某一类型通知，广播改变。
- (void) postMessage
{
[[NSNotificationCenter defaultCenter] postNotificationName:kDZTestNotificatonMessage object:Nil userInfo:@{}];
}
通知对象NSNotification，当有通知来的时候，Center会调用观察者注册的接口来广播通知，同时传递存储着更改内容的NSNotification对象。
apple版实现的NotificationCenter让我用起来不太爽的几个小问题
在使用NSNotificationCenter的时候，从编程的角度来讲我们往往不止是希望能够做到功能实现，还能希望编码效率和整个工程的可维护性良好。而Apple提供的以NSNotificationCenter为中心的观察者模式实现，在可维护性和效率上存在以下缺点：
每个注册的地方需要同时注册一个函数，这将会带来大量的编码工作。仔细分析能够发现，其实我们每个观察者每次注册的函数几乎都是雷同的。这就是种变相的CtrlCV，是典型的丑陋和难维护的代码。
每个观察者的回调函数，都需要对主题对象发送来的消息进行解包的操作。从UserInfo中通过KeyValue的方式，将消息解析出来，而后进行操作。试想一下，工程中有100个地方，同时对前面中在响应变化的函数中进行了解包的操作。而后期需求变化需要多传一个内容的时候，将会是一场维护上的灾难。
当大规模使用观察者模式的时候，我们往往在dealloc处加上一句:
[[NSNotificationCenter defaultCenter] removeObserver:self]
而在实际使用过程中，会发现该函数的性能是比较低下的。在整个启动过程中，进行了10000次RemoveObserver操作，
@implementation DZMessage
- (void) dealloc
{
[[NSNotificationCenter defaultCenter] removeObserver:self];
}
....
for (int i = 0 ; i < 10000; i++) {
DZMessage* message = [DZMessage new];
}
通过下图可以看出这一过程消耗了23.4%的CPU，说明这一函数的效率还是很低的。
ios desing pattern observer 6
这还是只有一种消息类型的存在下有这样的结果，如果整个NotificationCenter中混杂着多种消息类型，那么恐怕对于性能来说将会是灾难性的。
for (int i = 0 ; i < 10000; i++) {
DZMessage* message = [DZMessage new];
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(handle) name:[@(i) stringValue] object:nil];
}
增加了多种消息类型之后，RemoveObserver占用了启动过程中63.9%的CPU消耗。
ios desing pattern observer 7
而由于Apple没有提供Center的源码，所以修改这个Center几乎不可能了。
改进版的有中心观察者模式（DZNotificationCenter）
GitHub地址�0�2在设计的时候考虑到以上用起来不爽的地方，进行了优化：
将解包到执行函数的操作进行了封装，只需要提供某消息类型的解包block和消息类型对应的protocol，当有消息到达的时候，消息中心会进行统一解包，并直接调用观察者相应的函数。
对观察者的维护机制进行优化（还未做完），提升查找和删除观察者的效率。
DZNotificationCenter的用法和NSNotificationCenter在注册和注销观察者的地方是一样的，不一样的地方在于，你在使用的时候需要提供解析消息的block。你可以通过两种方式来提供。
直接注册的方式
[DZDefaultNotificationCenter addDecodeNotificationBlock:^SEL(NSDictionary *userInfo, NSMutableArray *__autoreleasing *params) {
NSString* key = userInfo[@"key"];
if (params != NULL) {
*params = [NSMutableArray new];
}
[*params addObject:key];
return @selector(handleTestMessageWithKey:);
} forMessage:kDZMessageTest];
实现DZNotificationInitDelegaete协议，当整个工程中大规模使用观察者的时候，建议使用该方式。这样有利于统一管理所有的解析方式。
- (DZDecodeNotificationBlock) decodeNotification:(NSString *)message forCenter:(DZNotificationCenter *)center
{
if (message == kDZMessageTest) {
return ^(NSDictionary* userInfo, NSMutableArray* __autoreleasing* params){
NSString* key = userInfo[@"key"];
if (params != NULL) {
*params = [NSMutableArray new];
}
[*params addObject:key];
return @selector(handlePortMessage:);
};
}
return nil;
}
在使用的过程中为了，能够保证在观察者处能够回调相同的函数，可以实现针对某一消息类型的protocol
@protocol DZTestMessageInterface <NSObject>
- (void) handleTestMessageWithKey:(NSString*)key;
@end
这样就能够保证，在使用观察者的地方不用反复的拼函数名和解析消息内容了。
@interface DZViewController () <DZTestMessageInterface>
@end
@implementation DZViewController
....
- (void) handleTestMessageWithKey:(NSString *)key
{
self.showLabel.text = [NSString stringWithFormat:@"get message with %@", key];
}
....
KVO
KVO的全称是Key-Value Observer，即键值观察。是一种没有中心枢纽的观察者模式的实现方式。一个主题对象管理所有依赖于它的观察者对象，并且在自身状态发生改变的时候主动通知观察者对象。 让我们先看一个完整的示例：
static NSString* const kKVOPathKey = @"key";
@implementation DZKVOTest
- (void) setMessage:(DZMessage *)message
{
if (message != _message) {
if (_message) {
[_message removeObserver:self forKeyPath:kKVOPathKey];
}
if (message) {
[message addObserver:self forKeyPath:kKVOPathKey options:NSKeyValueObservingOptionNew context:Nil];
}
_message = message;
}
}
- (void) observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context
{
if ([keyPath isEqual:kKVOPathKey] && object == _message) {
NSLog(@"get %@",change);
}
}
- (void) postMessage
{
_message.key = @"asdfasd";
}
@end
Ⅲ 什么是观察者模式(Observer)
观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生变化时，会通知所有观察者对象，让他们能够自动更新自己 观察者模式的组成 抽象主题角色：把所有对观察者对象的引用保存在一个集合中，每个抽象主题角色都可以有任意数量的观察者。抽象主题提供一个接口，可以增加和删除观察者角色。一般用一个抽象类或接口来实现。 抽象观察者角色：为所有具体的观察者定义一个接口，在得到主题的通知时更新自己。 从AWT1.1开始图形系统的事件模型采用观察者模式，因此观察者模式在Java语言中的地位极其重要 在xml解析中的SAX也采用了观察者模式来实现 Java也提供了对观察者模式的内置支持 Observable类用于创建可以观测到你的程序中其他部分的子类。当这种子类的对象发生变化时，观测类被通知。观测类必须实现定义了update(
Ⅳ Java设计模式求助（命令模式）
先说一下命令模式，举一个例子说明一下，玉帝传美猴王上天，玉帝创建了一个命令就是圣旨，然后指出圣旨的接受者美猴王，而太白金星只是传达命令的人。这个过程就是命令模式的应用。
这个好处就是玉帝将不会直接和美猴王打交道，他只需把命令封装在圣旨中交给太白金星传达即可其他的事他就不用问了。
下面再来解释一下观察者模式，还以西游记为例，唐三藏被红孩儿所困，孙悟空为救他去求菩萨，而菩萨听后将自己的宝珠净瓶向海中一掼，只见一只乌龟驮了一只瓶子上来。。。。这个乌龟就是观察者，被观察的对象就是菩萨，这里面就可以看出命令模式与之区别，乌龟是等待观察菩萨的动作，而玉帝是自己发出命令。这里面有时候很会乱的，观察者看的是乌龟怎么来实现，而命令是看发命令的人怎么安排的。。。。
说的不好，请多谅解！
Ⅳ 观察者模式是什么
官方解释：
观察者模式（有时又被称为发布-订阅Subscribe>模式、模型-视图View>模式、源-收听者Listener>模式或从属者模式）是软件设计模式的一种。在此种模式中，一个目标物件管理所有相依于它的观察者物件，并且在它本身的状态改变时主动发出通知。这通常透过呼叫各观察者所提供的方法来实现。此种模式通常被用来实作事件处理系统。
个人理解：
观察者模式是一种思想，不需要人为的去关注观察者和被观察者之间是怎样联系的，实现了解耦，只需要对象去注册被观察者（Observerable）与观察者(Observer)，然后被观察者去添加一个或者多个观察者，当被观察者发生变动就会立即通知所有的观察者，下面让我们来看看是怎样实现这个功能的。
被观察者首先通过addObserver(Observer o)来添加一个观察者，底层代码中会把这个对象o放进一个vector集合中，当然也可以添加多个观察者，当观察者发生变动的时候就会触发
setChanged();
notifyObservers();
这两个方法，然后底层代码中就回去遍历装有观察者的那个vector，然后
for (int i = arrLocal.length-1; i>=0; i--)
((Observer)arrLocal[i]).update(this, arg);
调用update方法通知每一个观察者，这样观察者对象中就可以拿到被观察者的相关对象和信息
Ⅵ java中什么叫"观察者设计模式"
才开始学习Java没有多久，看过了不少基础类的书籍，正尝试着做一些基础性的项目来整合零散的知识点。偶然之下在网上查资料时看到别人文章里提及"观察者设计模式"，突然很诧异，没有听说过这种模式呢~故而在网上搜集了一些资料又在图书馆找了一下相关书籍来学习。突然觉得也来学学他人，做做笔记吧~例如:现在很多的购房者都在关注房子的价格变化，每当房子价格变化时，所有 购房者都可以观察得到，实际上以上的购房者都属于观察者，他们都在关注着房子的价格。。其实这就叫观察者设计模式。由java.util包中提供的Observable类和Observer接口便可以轻松实现观察者模式，需要被观察的类必须继承Observable类。Observable类的常用方法有：public void addObserver(Observer o) ; public void deleteObserver(Observero); public void update(Observable o,Object arg);protected void setChanged(); //被观察者状态发生改变public void notifyObservers(Object arg) //通知所有观察者状态已改变对观察者模式的第一感觉是，实现此模式应该可以大大简化代码，使相关功能的代码块语义更清晰. 具体还得在以后应用中慢慢体悟下附一个观察者模式的实现：package org.lxh.demoll.obserdemo;import java.util.Observable;
import java.util.Observer;
class House extends Observable{
private float price;
public House(float price){
this.price = price;
}
public void setPrice(float price){
super.setChanged();
super.notifyObservers(price);
this.price=price;
}
public String toString(){
return "房子价格为：" + this.price;
}
}
class HousePriceObserver implements Observer{
private String name;
public HousePriceObserver(String name){
this.name = name;
}
public void update(Observable obj,Object arg){
if(arg instanceof Float){
System.out.println(this.name+"观察到价格是否更改为：");
System.out.println(((Float) arg).floatValue());
}
}
}
public class ObserDemo01{
public static void main(String[] args){
House h = new House(1000000);
HousePriceObserver hpo1 = new HousePriceObserver("购房者A");
HousePriceObserver hpo2 = new HousePriceObserver("购房者B");
HousePriceObserver hpo3 = new HousePriceObserver("购房者C");
h.addObserver(hpo1);
h.addObserver(hpo2);
h.addObserver(hpo3);
System.out.println(h);
h.setPrice(666666);
System.out.println(h);
}
}
Ⅶ 观察者模式和发布/订阅模式的区别
观察者（Observer）模式又名发布-订阅（Publish/Subscribe）模式。GOF给观察者模式如下定义：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
在这里先讲一下面向对象设计的一个重要原则——单一职责原则。因此系统的每个对象应该将重点放在问题域中的离散抽象上。因此理想的情况下，一个对象只做一件事情。这样在开发中也就带来了诸多的好处：提供了重用性和维护性，也是进行重构的良好的基础。
因此几乎所有的设计模式都是基于这个基本的设计原则来的。观察者模式的起源我觉得应该是在GUI和业务数据的处理上，因为现在绝大多数讲解观察者模式的例子都是这一题材。但是观察者模式的应用决不仅限于此一方面。
下面我们就来看看观察者模式的组成部分。
1) 抽象目标角色（Subject）：目标角色知道它的观察者，可以有任意多个观察者观察同一个目标。并且提供注册和删除观察者对象的接口。目标角色往往由抽象类或者接口来实现。
2) 抽象观察者角色（Observer）：为那些在目标发生改变时需要获得通知的对象定义一个更新接口。抽象观察者角色主要由抽象类或者接口来实现。
3) 具体目标角色（Concrete Subject）：将有关状态存入各个Concrete Observer对象。当它的状态发生改变时, 向它的各个观察者发出通知。
4) 具体观察者角色（Concrete Observer）：存储有关状态，这些状态应与目标的状态保持一致。实现Observer的更新接口以使自身状态与目标的状态保持一致。在本角色内也可以维护一个指向Concrete Subject对象的引用。
Ⅷ 观察者模式的基本简介
观察者模式（Observer）完美的将观察者和被观察的对象分离开。举个例子，用户界面可以作为一个观察者，业务数据是被观察者，用户界面观察业务数据的变化，发现数据变化后，就显示在界面上。面向对象设计的一个原则是：系统中的每个类将重点放在某一个功能上，而不是其他方面。一个对象只做一件事情，并且将他做好。观察者模式在模块之间划定了清晰的界限，提高了应用程序的可维护性和重用性。
观察者设计模式定义了对象间的一种一对多的依赖关系，以便一个对象的状态发生变化时，所有依赖于它的对象都得到通知并自动刷新。
Ⅸ 谁给我解释下啥叫做观察者模式
官方的定义：
The Observer Pattern defines a one-to-many dependency between objects so that when one object changes state, all of its dependents are notified and updated automatically. (观察者模式定义了对象间的一种一对多依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并被自动更新)
Ⅹ python中观察者模式的作用
在现实国际中，许多方针并不是独立存在的，其间一个方针的行为产生改动可能会导致一个或许多个其他方针的行为也产生改动。
这样的例子还有许多，例如小偷与警察,猫和老鼠等
观察者形式就如一个聊天室，当你需要收到聊天室的音讯时，你就注册成为聊天室的成员，当聊天室有信息更新时，就会传到你那去。当你不需要接收聊天室的信息时，能够注销掉，退出聊天室。
2.形式的界说与特点
降低了方针与观察者之间的耦合联系，两者之间是抽象耦合联系。
方针与观察者之间建立了一套触发机制。
4.它的主要缺陷如下
经过前面的分析与应用实例可知观察者形式适合以下几种情形。<ol font-size:14px;background-color:#faf7ef;"="" style="font-family: "sans serif", tahoma, verdana, helvetica; font-size: 12px; white-space: normal; color: rgb(57, 57, 57);">
方针间存在一对多联系，一个方针的状况产生改动会影响其他方针。
当一个抽象模型有两个方面，其间一个方面依靠于另一方面时，可将这二者封装在独立的方针中以使它们能够各自独立地改动和复用。