观察者模式
面试常见设计模式
面试常见设计模式设计模式是软件开发中常用的一种设计思想，它提供了一种解决问题的方法和模板，帮助开发人员在面对各种复杂问题时能够快速有效地进行设计和开发。
在面试时，设计模式也是面试官经常会问到的一个重要话题。
本文将介绍一些常见的设计模式，并分析其应用场景和优缺点。
1.单例模式单例模式是一种常见的创建型设计模式，它确保一个类只有一个实例，并提供一个全局访问点。
在多线程环境下，单例模式可以保证线程安全。
单例模式常用于需要共享资源或控制资源访问的场景，比如数据库连接池、线程池等。
2.工厂模式工厂模式是一种创建型设计模式，它定义了一个创建对象的接口，但具体的对象创建由子类决定。
工厂模式可以隐藏对象的创建细节，减少依赖，并且提供了一种可扩展的方式来创建对象。
工厂模式常用于创建复杂对象或对象组合的场景。
3.观察者模式观察者模式是一种行为型设计模式，它定义了一种一对多的依赖关系，当一个对象的状态发生变化时，其依赖的对象将自动收到通知并进行相应的处理。
观察者模式可以实现松耦合，增加对象之间的协作和交互。
观察者模式常用于事件驱动、消息通知等场景。
4.策略模式策略模式是一种行为型设计模式，它将一组算法封装成一系列可互换的策略，使得算法的变化独立于使用算法的客户端。
策略模式可以提高代码的可维护性和可扩展性，减少代码的重复和耦合。
策略模式常用于需要根据不同情况选择不同算法的场景。
5.装饰器模式装饰器模式是一种结构型设计模式，它动态地给一个对象添加一些额外的功能，同时又不改变其原有的结构。
装饰器模式可以在不需要子类化的情况下扩展对象的功能，符合开闭原则。
装饰器模式常用于动态地给对象添加新的行为或功能。
6.适配器模式适配器模式是一种结构型设计模式，它将一个类的接口转换成客户端所期望的另一个接口，使得原本不兼容的接口可以一起工作。
适配器模式可以提高代码的复用性和灵活性，减少代码的改动。
适配器模式常用于不同系统之间的接口转换或旧系统的升级迁移。
MQ的几种模式范文
MQ的几种模式范文MQ（消息队列）是一种异步通信机制，用于解耦发送者和接收者之间的消息传递。
它可以实现系统中不同模块之间的解耦，提高系统的可伸缩性和可靠性。
常见的MQ模式有点对点模式、发布-订阅模式和观察者模式等。
下面将详细介绍这几种MQ模式。
1. 点对点模式（Point-to-Point）点对点模式是一种最简单的MQ模式，也被称为队列模式。
在点对点模式中，消息发送者将消息发送到特定的消息队列，然后接收者从队列中读取消息。
每个消息只能被一个接收者消费，消费之后消息从队列中被删除。
点对点模式适用于发送端和接收端之间的通信是一对一的关系。
点对点模式的特点：-可靠性高：消息被发送到队列中后，即使接收者暂时不可用，消息也不会丢失。
-顺序性强：消息会按照发送顺序被接收者依次消费。
-灵活性低：发送者和接收者之间是一对一的关系，发送者和接收者都需要知道队列的存在。
2. 发布-订阅模式（Publish-Subscribe）发布-订阅模式是一种广播的消息传递方式。
在发布-订阅模式中，消息发送者（发布者）将消息发布到主题（Topic）上，然后多个接收者（订阅者）订阅该主题，接收者会同时接收到发布者发布的消息。
发布-订阅模式的特点：-异步通信：发布者和订阅者之间是异步通信，发送者不需要等待接收者的响应。
-高吞吐量：发布者发布消息后，所有订阅该主题的订阅者都会同时接收到消息，提高系统的处理能力。
-松耦合：发布者和订阅者之间通过主题进行解耦，发布者只管发布消息，订阅者只管订阅主题。
3. 观察者模式（Observer）观察者模式是一种常见的设计模式，也可以用于消息队列的实现。
在观察者模式中，主题（Subject）维护了一组观察者（Observer），当主题发生变化时，会通知所有观察者进行相应的处理。
观察者模式在消息队列中被广泛应用，用于解耦消息发送者和接收者之间的关系。
消息发送者充当主题，消息接收者充当观察者。
当消息发送者发送消息时，会通知所有观察者进行处理。
observer方法
observer方法Observer方法，也称为观察者模式，是一种软件设计模式，旨在使对象之间的变化自动通知其相关对象，而不需要直接的耦合。
在这种模式下，一个对象（通常是主题或发布者）维护一个由许多其他对象（观察者或订阅者）组成的列表，该列表保持更新，以便在主题状态发生变化时自动通知观察者对象。
这种模式可以在许多不同的环境中使用，并且已被证明是提高代码的可读性和可维护性的重要工具。
如何使用observer方法Observer方法可以通过简单的6步过程来使用：1. 定义主题。
主题的作用是维护一个当前状态，并能够通知所有观察者任何更改。
主题通常具有添加和删除观察者的方法，以及通知所有观察者的方法。
2. 定义观察者。
观察者的作用是接收主题通知，并作出相应的响应。
观察者通常具有update方法，该方法接收当前主题状态作为参数。
3. 如果您使用的被观察者对象已经存在，则将其更改为被观察者。
否则，可以轻松地创建具有被观察者属性的类，并且在观察者与主题之间使用该属性来保持通信。
4. 将所有观察者注册到主题中。
反之，您应该使用主题的注册方法将它们添加到列表中。
5. 实现主题状态更改的行为。
例如，可以添加一个setter方法，以便将更改状态后通知所有观察者。
6. 实现观察者的反应。
根据情况，观察者可能选择使用更改的状态进行计算，更新其自己的状态，或者执行其他必要的操作。
观察者模式的优点Observer方法有以下几个主要优点：1. 可扩展性。
由于观察者模式是松耦合的，因此在需要添加或移除观察者时非常灵活。
添加新观察者或删除现有观察者不需要更改主题或观察者的现有代码，因此添加和删除观察者可以在运行时执行。
2. 可重用性。
观察者模式使得可以将同样的观察者应用于多个主题，而不需要每次都重新编写代码。
3. 易于维护。
由于观察者模式模块化，因此在代码中更容易隔离和测试各个组件。
4. 易于实现。
观察者模式的实现通常是简单，易于理解和实现。
观察者原理
观察者原理
观察者原理，又称为观察者模式或发布-订阅模式，是一种软件设计模式，用于在对象之间建立一对多的依赖关系，使得当一个对象的状态发生改变时，所有依赖于它的对象都能够得到通知和自动更新。
观察者原理的核心思想是将一个目标对象与多个观察者对象进行解耦，目标对象维护一个观察者列表，当目标对象的状态发生改变时，会遍历观察者列表，并调用每个观察者对象的更新方法，通知它们更新自己的状态。
在观察者模式中，目标对象和观察者对象分别扮演着不同的角色。
目标对象是被观察的对象，它负责维护观察者列表和通知观察者。
观察者对象则是接收目标对象的通知，并进行相应处理的对象。
观察者对象之间相互独立，它们可以根据自己的需求来决定是否对特定的目标对象进行观察。
观察者原理的优点是能够提高对象之间的松耦合性，使得目标对象和观察者对象可以独立地演化和重用。
同时，观察者原理也具有较好的扩展性，可以灵活地增加新的观察者对象。
然而，观察者原理也存在一些缺点。
首先，观察者模式可能会导致系统中观察者对象过多，增加了对象之间的交互复杂性。
其次，观察者模式在通知观察者时，是按照固定的顺序调用其更新方法的，这可能会导致顺序依赖的问题。
总的来说，观察者原理是一种简单而实用的设计模式，在许多
场景下都有广泛应用，如事件驱动系统、消息队列等。
通过将观察者对象与目标对象解耦，观察者原理能够提供一种可靠、灵活的通信机制，使得系统更加健壮和可扩展。
java 面向对象的常用设计模式
java 面向对象的常用设计模式java 面向对象的常用设计模式有：1、观察者模式观察者模式又称为发布-订阅模式，定义了对象之间一对多依赖关系，当目标对象(被观察者)的状态发生改变时，它的所有依赖者(观察者)都会收到通知。
2、抽象工厂模式抽象工厂模式主要用于创建相关对象的家族。
当一个产品族中需要被设计在一起工作时，通过抽象工厂模式，能够保证客户端始终只使用同一个产品族中的对象；并且通过隔离具体类的生成，使得客户端不需要明确指定具体生成类；所有的具体工厂都实现了抽象工厂中定义的公共接口，因此只需要改变具体工厂的实例，就可以在某种程度上改变整个软件系统的行为。
3、单例设计模式单例设计模式可以确保系统中某个类只有一个实例，该类自行实例化并向整个系统提供这个实例的公共访问点，除了该公共访问点，不能通过其他途径访问该实例。
4、策略模式将类中经常改变或者可能改变的部分提取为作为一个抽象策略接口类，然后在类中包含这个对象的实例，这样类实例在运行时就可以随意调用实现了这个接口的类的行为。
比如定义一系列的算法，把每一个算法封装起来，并且使它们可相互替换，使得算法可独立于使用它的客户而变化，这就是策略模式。
5、适配器模式适配器模式主要用于将一个类或者接口转化成客户端希望的格式，使得原本不兼容的类可以在一起工作，将目标类和适配者类解耦；同时也符合“开闭原则”，可以在不修改原代码的基础上增加新的适配器类；将具体的实现封装在适配者类中，对于客户端类来说是透明的，而且提高了适配者的复用性，但是缺点在于更换适配器的实现过程比较复杂。
6、命令模式命令模式的本质是将请求封装成对象，将发出命令与执行命令的责任分开，命令的发送者和接收者完全解耦，发送者只需知道如何发送命令，不需要关心命令是如何实现的，甚至是否执行成功都不需要理会。
命令模式的关键在于引入了抽象命令接口，发送者针对抽象命令接口编程，只有实现了抽象命令接口的具体命令才能与接收者相关联。
设计模式Observor模式
观察者模式——定义
观察者模式(有时又被称为发布/订阅模式)是软体设 计模式的一种。在此种模式中，一个被观察者（消息主 题）管理所有相依于它的观察者物件，并且在它本身的 状态改变时主动发出通知（其实就是调用所有观察者的 相关方法）。此种模式通常被用来实作事件处理系统ava内置的观察者模式
Java.util包内包含最基本的Observer接口 与Observable类 Subject extends Observable Subscriber implements Observer
在JDK中，还有哪些观察者模式
关键字：
被观察者，观察者
主题(Subject)，订阅者(Subscriber) 发布（Publish），订阅（Subscribe）
Observer(观察者)模式
观察者模式 = 订阅 + 广播 类比：邮局报刊订阅
你向邮局订阅报刊 邮局把你加入订阅人列表 每当有新的报纸，邮局会及时送到每个订阅人手 中 当你不需要该报纸时，你向邮局退订，从此邮局 不再给你送报纸
AWT API:Button 超类AbstractButton有许多增加和删除倾 听者（listener)的方法 Button.addActionListerner(ActionListe rner actionListerner)
软件工程师中的常见设计模式
软件工程师中的常见设计模式设计模式是软件开发中经验丰富的工程师在解决特定问题时总结出的一种模式或思想，它可以提供一套解决方案，帮助开发人员降低系统的复杂性，并增加代码的可读性和可维护性。
在软件工程师的日常开发过程中，熟悉和掌握常见的设计模式是非常重要的。
本文将介绍一些常见的设计模式，以帮助软件工程师更好地应用设计模式。
一、单例模式单例模式是一种创建型的设计模式，它的主要目的是确保一个类只有一个实例，并提供一个全局访问点。
在软件开发中，我们常常需要保证某个类的实例只有一个，比如数据库连接池、线程池等。
使用单例模式可以有效地避免资源的浪费和冲突。
单例模式的实现方式有多种，其中最常见的是饿汉式和懒汉式。
饿汉式是在类加载时就创建实例，而懒汉式是在首次使用时才创建实例。
二、工厂模式工厂模式是一种创建型的设计模式，它的主要目的是将具体对象的创建和客户端的使用相分离。
工厂模式通过一个工厂类来负责创建对象，客户端只需要调用工厂类的方法即可获取所需的对象，而不需要关心具体对象的创建过程。
工厂模式有三种常见的实现方式：简单工厂模式、工厂方法模式和抽象工厂模式。
简单工厂模式通过一个工厂类来创建所有的对象，工厂方法模式通过一个工厂接口和多个具体工厂类来创建对象，抽象工厂模式通过多个工厂接口和多个具体工厂类来创建对象。
三、观察者模式观察者模式是一种行为型的设计模式，它的主要目的是定义了对象之间的一对多依赖关系，使得当一个对象状态发生改变时，其他依赖于它的对象都会收到通知并自动更新。
观察者模式由两个核心角色组成：观察者和被观察者。
其中被观察者维护着一个观察者列表，并提供注册和注销观察者的方法，而观察者通过接收被观察者的通知并执行相应的操作。
四、策略模式策略模式是一种行为型的设计模式，它的主要目的是定义了一系列的算法，并将其封装成独立的对象，使得这些算法可以互相替换。
通过使用策略模式，可以使得算法和客户端解耦，客户端无需关心具体的算法实现细节。
观察者模式
观察者模式（Observer）
1.观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一
个主体对象。
这个主体对象在状态上发生变化时，会通知所有观察者对象，让他们能够自动更新自己
2.观察者模式的组成
1-抽象主题角色：把所有对观察者对象的引用保存在一个集合中，每个抽象主题角色都可以有任意数量的观察者。
抽象主题提供一个接口，可以增加和删除观察者角色。
一般用一个抽象类或接口来实现。
2-抽象观察者角色：为所有具体的观察者定义一个接口，在得到主题的通知时更新自己
3-具体主题角色：在具体主题内部状态改变时，给所有登记过的观察者发出通知。
具体主题角色通常用一个子类实现
4-具体观察者角色：该角色实现抽象观察者角色所要求的更新接口，以便使本身的状态与主题的状态相协调。
如果需要，具体观察者角色可以保存一个指向具体主题角色的引用。
通常用一个子类实现。
《观察者模式》课件
注册与注销
注册
观察者通过调用主题的注册方法将自己注册到主题中，以便在主题状态发生变 化时接收通知。
注销
观察者可以通过调用主题的注销方法将自己从主题中注销，以停止接收通知。
通知机制
当主题的状态发生变化时，主题会调用其通知方法，将当前 状态传递给所有注册的观察者。
02
观察者模式的核心概念
主题（Subject）
01
主题负责维护一个或多个观察者 对象的引用，当主题的状态发生 变化时，通知所有注册的观察者 。
02
主题通常具有注册和注销观察者 的方法，以及一个用于通知所有 注册观察者的方法。
观察者（Observer）
观察者负责实现更新操作，当主题的 状态发生变化时，观察者会收到通知 并执行相应的更新操作。
C#中的观察者模式实现
• void Update(int data);
C#中的观察者模式实现
01
}
02
public class Publisher {
03
private int _data;
C#中的观察者模式实现
private List<IObserver> _observers = new List<IObserver>();
在事件驱动架构中，观察者模式可以用于监听特定事件的发生，并触发相应的处 理流程。当事件发生时，系统会自动调用相关处理函数或执行相关操作，实现事 件处理和流程的自动化，提高系统的响应速度和灵活性。
06
总结与展望
观察者模式的总结
观察者模式的主要优点在于能够实现发布/订阅模型 ，使得多个观察者可以同时监听一个主题，提高了系 统的可扩展性和可维护性。
设计模式之观察者模式（Observer）详解及代码示例
设计模式之观察者模式（Observer）详解及代码⽰例⼀、模式的定义与特点 观察者（Observer）模式的定义：观察者模式⼜被称为发布-订阅/模型-视图模式，属于⾏为型设计模式的⼀种，是⼀个在项⽬中经常使⽤的模式。
指多个对象间存在⼀对多的依赖关系，当⼀个对象的状态发⽣改变时，所有依赖于它的对象都得到通知并被⾃动更新。
⼆、观察者模式优缺点 观察者模式是⼀种对象⾏为型模式，其主要优点如下：降低了⽬标与观察者之间的耦合关系，两者之间是抽象耦合关系。
⽬标与观察者之间建⽴了⼀套触发机制。
它的主要缺点如下：⽬标与观察者之间的依赖关系并没有完全解除，⽽且有可能出现循环引⽤。
当观察者对象很多时，通知的发布会花费很多时间，影响程序的效率。
三、观察者模式的实现 实现观察者模式时要注意具体⽬标对象和具体观察者对象之间不能直接调⽤，否则将使两者之间紧密耦合起来，这违反了⾯向对象的设计原则。
观察者模式的主要⾓⾊如下。
抽象主题（Subject）⾓⾊：也叫抽象⽬标类，它提供了⼀个⽤于保存观察者对象的聚集类和增加、删除观察者对象的⽅法，以及通知所有观察者的抽象⽅法。
具体主题（Concrete Subject）⾓⾊：也叫具体⽬标类，它实现抽象⽬标中的通知⽅法，当具体主题的内部状态发⽣改变时，通知所有注册过的观察者对象。
抽象观察者（Observer）⾓⾊：它是⼀个抽象类或接⼝，它包含了⼀个更新⾃⼰的抽象⽅法，当接到具体主题的更改通知时被调⽤。
具体观察者（Concrete Observer）⾓⾊：实现抽象观察者中定义的抽象⽅法，以便在得到⽬标的更改通知时更新⾃⾝的状态。
观察者模式的结构图如图所⽰： 代码如下：public class ObserverPattern{public static void main(String[] args){Subject subject=new ConcreteSubject();Observer obs1=new ConcreteObserver1();Observer obs2=new ConcreteObserver2();subject.add(obs1);subject.add(obs2);subject.notifyObserver();}}//抽象⽬标abstract class Subject{protected List<Observer> observers=new ArrayList<Observer>();//增加观察者⽅法public void add(Observer observer){observers.add(observer);}//删除观察者⽅法public void remove(Observer observer){observers.remove(observer);}public abstract void notifyObserver(); //通知观察者⽅法}//具体⽬标class ConcreteSubject extends Subject{public void notifyObserver(){System.out.println("具体⽬标发⽣改变...");System.out.println("--------------");for(Object obs:observers){((Observer)obs).response();}}}//抽象观察者interface Observer{void response(); //反应}//具体观察者1class ConcreteObserver1 implements Observer{public void response(){System.out.println("具体观察者1作出反应！");}}//具体观察者1class ConcreteObserver2 implements Observer{public void response(){System.out.println("具体观察者2作出反应！");}} 测试结果为：具体⽬标发⽣改变...--------------具体观察者1作出反应！具体观察者2作出反应！四、观察者模式的应⽤实例 接下来再看⼀个关于上下课打铃，⽼师同学上下课的⽰例：public class BellEventTest{public static void main(String[] args){BellEventSource bell=new BellEventSource(); //铃（事件源）bell.addPersonListener(new TeachEventListener()); //注册监听器（⽼师） bell.addPersonListener(new StuEventListener()); //注册监听器（学⽣）bell.ring(true); //打上课铃声System.out.println("------------");bell.ring(false); //打下课铃声}}//铃声事件类：⽤于封装事件源及⼀些与事件相关的参数// EventObject: The root class from which all event state objects shall be derived. class RingEvent extends EventObject{private static final long serialVersionUID=1L;private boolean sound; //true表⽰上课铃声,false表⽰下课铃声public RingEvent(Object source,boolean sound){super(source);this.sound=sound;}public void setSound(boolean sound){this.sound=sound;}public boolean getSound(){return this.sound;}}//⽬标类：事件源，铃class BellEventSource{private List<BellEventListener> listener; //监听器容器public BellEventSource(){listener=new ArrayList<BellEventListener>();}//给事件源绑定监听器public void addPersonListener(BellEventListener ren){listener.add(ren);}//事件触发器：敲钟，当铃声sound的值发⽣变化时，触发事件。
观察者模式
Observer观察者模式作用：观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象，这个主题对象在状态发生变化时，会通知所有观察者对象，使它们能够自动更新自己UML图：Subject类，可翻译为主题或抽象通知者，一般用一个抽象类或者一个借口实现。
它把所有对观察者对象的引用保存在一个聚集里，每个主题都可以有任何数量的观察者。
抽象主题提供一个借口，可以增加和删除观察者对象。
Observer类，抽象观察者，为所有的具体观察者定义一个借口，在得到主题的通知时更新自己。
这个借口叫做更新接口。
抽象观察者一般用一个抽象类或者一个接口实现。
更新接口通常包含一个Update()方法。
ConcreteSubject类，叫做具体主题或具体通知者，将有关状态存入具体通知者对象；在具体主题的内部状态改变时，给所有等级过的观察者发出通知。
通常用一个具体子类实现。
ConcreteObserver类，具体观察者，实现抽象观察者角色所要求的更新接口，以便使本身的状态与主题的状态相协调。
具体观察者角色可以保存一个指向一个具体主题对象的引用。
特点：将一个系统分割成一系列相互协作的类有一个很不好的副作用，那就是需要维护相关对象间的一致性。
我们不希望为了维持一致性而使各类紧密耦合，这样会给维护、扩展和重用都带来不便。
何时使用：当一个对象的改变需要同时改变其他对象的时候，而且它不知道具体有多少对象有待改变时，应该考虑使用观察者模式。
观察者模式所做的工作其实就是在解除耦合。
让耦合的双方都依赖于抽象，而不是依赖于具体。
从而使得各自的变化都不会影响另一边的变化。
代码如下：Observer.h1 #ifndef _OBSERVER_H_2#define _OBSERVER_H_34 #include <string>5 #include <list>6using namespace std;78class Subject;910class Observer11 {12public:13 ~Observer();14virtual void Update(Subject*)=0;15protected:16 Observer();17private:18 };1920class ConcreteObserverA : public Observer21 {22public:23 ConcreteObserverA();24 ~ConcreteObserverA();25virtual void Update(Subject*);26protected:27private:28string m_state;29 };3031class ConcreteObserverB : public Observer32 {33public:34 ConcreteObserverB();35 ~ConcreteObserverB();36virtual void Update(Subject*);37protected:38private:39string m_state;40 };4142class Subject43 {44public:45 ~Subject();46virtual void Notify();47virtual void Attach(Observer*);48virtual void Detach(Observer*);49virtual string GetState();50virtual void SetState(string state); 51protected:52 Subject();53private:54string m_state;55 list<Observer*> m_lst;56 };5758class ConcreteSubjectA : public Subject 59 {60public:61 ConcreteSubjectA();62 ~ConcreteSubjectA();63protected:64private:65 };6667class ConcreteSubjectB : public Subject 68 {69public:70 ConcreteSubjectB();71 ~ConcreteSubjectB();72protected:73private:74 };7576#endifObserver.cpp1 #include "Observer.h"2 #include <iostream>3 #include <algorithm>45using namespace std;67 Observer::Observer()8 {}910 Observer::~Observer()11 {}1213 ConcreteObserverA::ConcreteObserverA()14 {}1516 ConcreteObserverA::~ConcreteObserverA()17 {}1819void ConcreteObserverA::Update(Subject* pSubject)20 {21this->m_state = pSubject->GetState();22 cout << "The ConcreteObserverA is " << m_state << std::endl;23 }2425 ConcreteObserverB::ConcreteObserverB()26 {}2728 ConcreteObserverB::~ConcreteObserverB()29 {}3031void ConcreteObserverB::Update(Subject* pSubject)32 {33this->m_state = pSubject->GetState();34 cout << "The ConcreteObserverB is " << m_state << std::endl;35 }3637 Subject::Subject()38 {}3940 Subject::~Subject()41 {}4243void Subject::Attach(Observer* pObserver)44 {45this->m_lst.push_back(pObserver);46 cout << "Attach an Observer\n";4849void Subject::Detach(Observer* pObserver)50 {51 list<Observer*>::iterator iter;52 iter = find(m_lst.begin(),m_lst.end(),pObserver);53if(iter != m_lst.end())54 {55 m_lst.erase(iter);56 }57 cout << "Detach an Observer\n";58 }5960void Subject::Notify()61 {62 list<Observer*>::iterator iter = this->m_lst.begin(); 63for(;iter != m_lst.end();iter++)64 {65 (*iter)->Update(this);66 }67 }6869string Subject::GetState()70 {71return this->m_state;72 }7374void Subject::SetState(string state)75 {76this->m_state = state;77 }7879 ConcreteSubjectA::ConcreteSubjectA()80 {}8182 ConcreteSubjectA::~ConcreteSubjectA()83 {}8485 ConcreteSubjectB::ConcreteSubjectB()86 {}8788 ConcreteSubjectB::~ConcreteSubjectB()89 {}#include "Observer.h"#include <iostream>using namespace std;int main(){Observer* p1 = new ConcreteObserverA();Observer* p2 = new ConcreteObserverB();Observer* p3 = new ConcreteObserverA();Subject* pSubject = new ConcreteSubjectA();pSubject->Attach(p1);pSubject->Attach(p2);pSubject->Attach(p3);pSubject->SetState("old");pSubject->Notify();cout << "-------------------------------------" << endl; pSubject->SetState("new");pSubject->Detach(p3);pSubject->Notify();return0;}结果如下：适用性：1．当一个抽象模型有两个方面, 其中一个方面依赖于另一方面。
五种常见设计模式
五种常见设计模式设计模式是软件开发中常见的解决问题的方式。
它们是经过实践验证的，可以用于解决特定类型问题的重复性的设计问题。
有许多种设计模式，本文将重点介绍五种常见的设计模式，并对每种设计模式进行详细的介绍。
1.单例模式：单例模式是一种常见的创建型设计模式，它用于限制一些类的实例化只能为一个对象。
这种模式适用于需要全局访问一个对象，且该对象只能有一个实例的情况。
单例模式的实现方式有多种，其中一种通用的方式是使用一个私有的静态变量来保存实例。
该变量只在第一次调用 getInstance( 方法时被初始化，并在后续调用中重复使用。
下面是一个简单的单例模式示例：```javapublic class Singletonprivate static Singleton instance;private Singleton( { }public static synchronized Singleton getInstancif (instance == null)instance = new Singleton(;}return instance;}```2.工厂模式：工厂模式是一种常见的创建型设计模式，它用于创建对象的过程与客户端代码分离。
工厂模式通过定义一个共同的接口，然后由子类来实现具体的工厂方法，从而创建不同的对象。
工厂模式有三种常见的实现方式：简单工厂模式、工厂方法模式和抽象工厂模式。
其中，简单工厂模式通过一个工厂类来决定实例化哪一个类；工厂方法模式通过一个工厂接口和多个具体工厂类来实现，每个具体工厂类负责创建一种具体的产品；抽象工厂模式通过一个抽象工厂接口和多个具体工厂类来实现，每个具体工厂类负责创建一族相关的产品。
3.观察者模式：观察者模式是一种常见的行为型设计模式，它定义了一种一对多的依赖关系，使得当一个对象改变状态时，其依赖者将自动收到通知并进行相应的更新。
观察者模式由两个核心组件组成：观察者和被观察者。
Observer模式
Observer模式 观察者模式（有时⼜被称为发布/订阅模式）是软件设计模式的⼀种。
在此种模式中，⼀个⽬标对象管理所有相依于它的观察者对象，并且在它本⾝的状态改变时主动发出通知。
这通常透过呼叫各观察者所提供的⽅法来实现。
此种模式通常被⽤来实作事件处理系统。
抽象⽬标类别 此抽象类别提供⼀个接⼝让观察者进⾏添附与解附作业。
此类别内有个不公开的观察者串炼，并透过下列函数(⽅法)进⾏作业： 添附(Attach)：新增观察者到链表中，以追踪⽬标对象的变化。
解附(Detach)：将已经存在的观察者从串炼中移除。
通知(Notify)：利⽤观察者所提供的更新函式来通知此⽬标已经产⽣变化。
添附函数包涵了⼀个观察者对象参数。
也许是观察者类别的虚函，或是在⾮⾯向对象的设定中所使⽤的函数。
⽬标类别 此类别提供了观察者欲追踪的状态。
也利⽤其源类别(例如前述的抽象⽬标类别)所提供的⽅法,来通知所有的观察者其状态已经更新。
此类别拥有以下函数： 取得状态(GetState)：回传该⽬标对象的状态。
抽象观察者接⼝ 抽象观察者类别是⼀个必须被实做的抽象类别。
这个类别定义了所有观察者都拥有的更新⽤接⼝，此接⼝是⽤来接收⽬标类别所发出的更新通知。
此类别含有以下函数： 更新(Update)：会被实做的⼀个抽象函数。
观察者类别 这个类别含有指向⽬标类别的参考(reference)，以接收来⾃⽬标类别的更新状态。
此类别含有以下函数： 更新(Update)：是前述抽象函式的实做。
当这个函数被⽬标对象调⽤时，观察者对象将会调⽤⽬标对象的取得状态函数，获取所拥有的更新⽬标对象信息。
每个观察者类别都要实做它⾃⼰的更新函数，以应对状态更新的情形。
当⽬标对象改变时，会通过调⽤它⾃⼰的通知函数来将通知送给每⼀个观察者对象，这个通知函数则会去调⽤已经添附在链表内的观察者更新函数。
通知与更新函数可能会有⼀些参数，好指明是⽬前⽬标对象内的何种改变。
这样做将可增进观察者的效率(只更新那些改变部份的状态)。
观察者模式和组合模式的区别
观察者模式和组合模式的区别观察者模式和组合模式是常见的面向对象设计模式，它们分别用于解决不同的问题。
观察者模式旨在实现对象之间的松耦合通信，而组合模式则用于描述部分与整体的关系。
本文将讨论这两种模式的区别。
1. 观察者模式观察者模式也称为发布-订阅模式，其核心思想是将一个对象的状态变化通知给其他依赖该状态的对象，以便这些对象能够及时更新自己的状态。
观察者模式包括两种角色：被观察者和观察者。
被观察者通常维护一个观察者列表，当其状态发生变化时，会遍历观察者列表，调用每个观察者的更新方法。
观察者则实现更新方法，以便被通知时进行相应的处理。
通过这种方式，观察者模式实现了松耦合的通信，使得被观察者和观察者之间可以相互独立地变化。
2. 组合模式组合模式用于描述部分与整体的关系，其核心思想是将对象组合成树形结构，使得用户可以像处理单个对象一样处理整个树形结构。
组合模式包括组合对象和叶子对象。
组合对象包含多个叶子对象和/或其他组合对象，其本身也是一个对象。
组合对象提供了访问其子对象的方法。
叶子对象则是最基本的对象，它不再包含其他对象。
通过这种方式，组合模式实现了部分与整体之间的递归结构，使得用户可以对整个树形结构进行统一的操作。
3. 区别观察者模式和组合模式虽然均属于面向对象设计模式，但其用途和实现方式不同。
首先，观察者模式解决的问题是松耦合通信，而组合模式解决的问题是部分与整体的关系。
观察者模式着重于对象之间的通信，而组合模式着重于对象之间的组合。
其次，观察者模式中被观察者和观察者是两种独立的角色，其依赖关系是单向的。
而组合模式中组合对象和叶子对象并不存在独立的角色，其依赖关系是双向的。
最后，观察者模式中观察者可以随时加入或退出被观察者的观察者列表，而组合模式中树形结构是在程序运行时构造的，其包含的内容在运行时不会发生变化。
4. 总结观察者模式和组合模式是两种常见而有用的设计模式。
它们分别解决了通信和组合的问题，让我们可以更好地设计和实现面向对象的程序。
模式比较方案
模式比较方案简介在软件开发过程中，选择合适的设计模式是一项非常重要的决策。
设计模式提供了一套解决常见软件设计问题的经验性解决方案。
在本文档中，我们将比较常见的设计模式，包括工厂模式、装饰器模式和观察者模式，并分析它们的应用场景、优点和缺点。
工厂模式定义工厂模式是一种创建对象的设计模式。
它定义了一个抽象工厂，负责封装对象的创建过程，而具体的对象创建交给子类实现。
应用场景工厂模式适用于以下场景：1.当一个对象的创建需要复杂的初始化过程时，可以将初始化逻辑抽象到工厂类中，简化客户端的调用。
2.当需要在运行时根据条件决定创建哪个具体对象时，可以使用工厂模式。
优点工厂模式的优点包括：1.封装了对象的创建过程，降低了客户端与具体对象的耦合性。
2.符合开闭原则，当需要创建新的对象时，只需要新增具体工厂类，而不需要修改已有代码。
缺点工厂模式的缺点包括：1.增加了系统的复杂度，引入了额外的类和接口。
2.当需要创建的对象很多时，会导致工厂类的职责过重。
装饰器模式定义装饰器模式是一种结构型设计模式。
它允许在不改变现有对象结构的情况下，动态地向对象添加额外的功能。
应用场景装饰器模式适用于以下场景：1.当需要动态地添加对象的额外功能时，可以使用装饰器模式。
2.当不能使用子类来扩展对象时，可以使用装饰器模式。
优点装饰器模式的优点包括：1.可以灵活地添加和删除功能，而无需修改现有对象的结构。
2.符合开闭原则，当需要添加新的功能时，只需要创建新的装饰器类，而不需要修改已有代码。
缺点装饰器模式的缺点包括：1.增加了系统的复杂度，引入了额外的类和接口。
2.当装饰器类很多时，可能会导致类的数量庞大。
观察者模式定义观察者模式是一种行为型设计模式。
它定义了一种一对多的依赖关系，当一个对象的状态发生改变时，它的所有依赖者都会接收到通知并自动更新。
应用场景观察者模式适用于以下场景：1.当一个对象需要将自己的变化通知其他对象时，可以使用观察者模式。
python中observer用法
观察者模式是软件开发中常用的一种设计模式，可以用于构建松耦合的系统。
在Python语言中，观察者模式（Observer Pattern）也有着广泛的应用。
本文将介绍Python中观察者模式的基本概念及其用法。
1. 观察者模式简介观察者模式是一种行为型设计模式，它定义了一种一对多的依赖关系，使得当一个对象的状态发生变化时，所有依赖于它的对象都会得到通知并自动更新。
观察者模式通常包括三个角色：主题（Subject）、观察者（Observer）和具体主题（Concrete Subject）、具体观察者（Concrete Observer）。
2. Python中观察者模式的实现在Python中，观察者模式可以通过以下几种方式来实现：（1）使用内置模块：Python提供了内置的模块用于实现观察者模式，例如`observable`和`observers`模块。
通过这些模块，可以轻松地创建观察者模式的实例，并实现通知和更新操作。
（2）自定义实现：除了使用内置模块，还可以自定义观察者模式的实现。
通过定义主题类和观察者类，并在主题类中注册观察者、通知观察者等操作，可以实现观察者模式。
3. 观察者模式的应用场景观察者模式广泛应用于以下几个方面：（1）事件处理：在GUI编程中，观察者模式常用于处理用户界面事件。
当用户执行某些操作时，界面的其他部分会自动更新。
（2）消息通知：在消息系统中，观察者模式可以用于实现消息的订阅和发布，当有新消息发布时，订阅者会自动收到通知。
（3）数据同步：在多线程或分布式系统中，观察者模式可以用于实现数据的同步，当数据发生变化时，各个观察者会同步更新。
4. Python中观察者模式的优缺点观察者模式有着诸多优点，例如：（1）松耦合：观察者模式可以使主题与观察者之间实现松耦合，主题对象只需要知道观察者接口即可。
（2）易扩展：新增观察者或者主题都不会影响到已有的对象，方便系统的扩展和维护。
（3）灵活性：可以随时增加或删除观察者，实现动态的变化。
观察者模式
.5 效果分析
观察者模式的应用场景： 对一个对象状态的更新，需要其他对象同步 更新，而且其他对象的数量动态可变。 对象仅需要将自己的更新通知给其他对象而 不需要知道其他对象的细节。
.5 效果分析
观察者模式的优点： Subject和Observer之间是松偶合的，分别 可以各自独立改变。 Subject在发送广播通知的时候，无须指定 具体的Observer，Observer可以自己决定是 否要订阅Subject的通知。 遵守大部分GRASP原则和常用设计原则， 高内聚、低偶合。
.1 观察者模式的由来
这一行为意味着表格对象和棒状图对象 都依赖于数据对象, 因此数据对象的任何状态改变都应立即 通知它们。同时也没有理由将依赖于该数 据对象的对象的数目限定为两个， 对相同 的数据可以有任意数目的不同用户界面。
.2 观察者模式的意图和适用性
模式的意图
定义对象间的一种一对多的依赖关系，当一个 对象的状态发生改变时，所有依赖于它的对象都得 到通知并被自动更新。
观察者模式(Oberserver)
一.观察者模式的由来 二.观察者模式的意图及适用性 三.观察者模式的结构及参与者 四.应用举例 五.效果说明
.1 观察者模式的由来
在制作系统的过程中，将一个系统分割成一系列相 互协作的类有一个常见的副作用：需要维护相关对象 间的一致性。我们不希望为了维持一致性而使各类紧 密耦合，因为这样降低了他们的可充用性。
.5 效果分析
观察者模式的缺陷： 松偶合导致代码关系不明显，有时可能难 以理解。 如果一个Subject被大量Observer订阅的话， 在广播通知的时候可能会有效率问题。
.1 观察者模式的由来
例如, 许多图形用户界面工具箱将用户应用的界面表示与底下的应用数据分 离。定义应用数据的类和负责界面表示的类可以各自独立地复用。当然它们也可 一起工作。一个表格对象和一个柱状图对象可使用不同的表示形式描述同一个应 用数据对象的信息。表格对象和柱状图对象互相并不知道对方的存在，这样使你 可以根据需要单独复用表格或柱状图。但在这里是它们表现的似乎互相知道。当 用户改变表格中的信息时,柱状图能立即反映这一变化, 反过来也是如此。
观察者模式简单例子
观察者模式简单例子
1. 嘿，你知道吗？就像你关注一个网红，你就是观察者，网红就是被观察者呀！比如说你特别喜欢的那个美食博主，每次他发布新视频你都第一时间知道，这就是观察者模式嘛！
2. 想想看，课堂上老师和学生，老师在讲台上一举一动，学生们都看着呢，学生们就是观察者呀！这多简单的例子呀，对吧！
3. 咱平常看电视剧的时候，你作为观众观察着剧中人物的悲欢离合，这不也是观察者模式嘛！就像追那部超火的剧，你不就时刻观察着主角们的故事发展嘛！
4. 再比如家长观察着孩子的成长，孩子的每一点进步家长都看在眼里，家长就是观察者啦。
你说这和观察者模式是不是很像哇！
5. 还有呢，球迷观察着自己喜欢的球队比赛，球员们在场上的表现都被球迷密切关注着，这就是一个很鲜活的观察者模式例子哟！
6. 去动物园的时候，我们游客观察着各种动物的行为，我们可是十足的观察者呀。
哎呀，这多明显呀！
7. 在公司里，领导观察着员工的工作状态，领导不就是那个观察者嘛！这不是和观察者模式一个道理嘛！
8. 走在路上，我们看着来来往往的路人，我们也是观察者呀！这些不都是生活中常见的观察者模式例子吗？
总之，观察者模式就在我们身边呀，随时随地都能发现呢！。
观察者模式的概念
观察者模式的概念嘿，朋友！今天咱们来聊聊观察者模式这个听起来有点神秘，但其实也没那么复杂的概念。
你想想啊，咱们生活中其实到处都有类似观察者模式的情况。
比如说，你在学校参加一场运动会，你是跑步选手，而在跑道边给你加油助威的同学们，他们不就是观察者嘛！他们看着你的表现，为你的每一次冲刺欢呼，为你的每一次超越鼓掌。
你在前面跑，他们在旁边观察，你的一举一动都被他们看在眼里，他们的情绪也随着你的表现而起伏。
再比如，你喜欢看的那些综艺节目。
舞台上的明星们尽情表演，而台下的观众就是观察者。
明星们的每一个动作、每一句台词，观众都看在眼里，然后给出各种各样的反应，欢呼、尖叫或者感动得落泪。
那到底啥是观察者模式呢？简单来说，就是有一些被观察的对象，就像前面说的跑步选手和表演的明星，然后还有一群观察这些对象的人，就像跑道边的同学和台下的观众。
被观察的对象一旦有啥变化或者做了啥动作，观察者就能马上知道，并且做出相应的反应。
比如说，在一个软件系统里，有一个数据对象，它的数值可能会随时变化。
然后呢，有好多模块都关心这个数值的变化。
这时候，就可以用观察者模式啦。
数据对象就是被观察的那个，而关心它的那些模块就是观察者。
一旦数据对象的值变了，它就会主动通知那些观察者，“嘿，我变啦，你们注意哦！”然后观察者们就可以根据这个变化去做自己该做的事情，比如更新显示、重新计算什么的。
这就好像你是一个厨师，你在厨房里做菜。
你的助手们就是观察者，他们看着你做菜的过程。
一旦你说“菜做好啦”，助手们就马上行动，有的负责装盘，有的负责端出去给客人。
观察者模式的好处可多啦！它能让系统的各个部分解耦，就是说各个部分之间的关系不那么紧密，不会因为一个部分的改变而影响到其他部分大乱套。
就像一辆汽车，发动机是被观察的对象，仪表盘就是观察者。
发动机工作状态变了，仪表盘能马上显示出来，但是仪表盘坏了，发动机照样能正常工作。
而且啊，观察者模式还能让系统更灵活。
如果想要增加新的观察者，或者去掉一些不需要的观察者，都很方便，不会对整个系统造成太大的影响。
obs教程
obs教程观察者模式（Observer Pattern），又称为发布-订阅模式（Publish-Subscribe Pattern），是一种软件设计模式，属于行为型模式的一种。
它定义了一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都会收到通知并自动更新。
它是一种松耦合的设计模式，能够使对象之间的关系更加灵活。
在观察者模式中，有两个核心的角色：主题（Subject）和观察者（Observer）。
主题是被观察的对象，它维护一系列的观察者，可以动态地添加或删除观察者。
当主题的状态发生改变时，它会通知所有的观察者并调用它们的更新方法。
观察者是依赖于主题的对象，它们将自己注册到主题上，以便接收主题的通知。
观察者模式的优点有：1. 降低了对象之间的耦合性。
主题只需要知道观察者接口就可以了，无需知道具体的观察者类。
这样使得主题和观察者可以独立地进行修改或重用。
2. 支持一对多的关系。
一个主题可以有多个观察者，当主题的状态发生改变时，所有的观察者都会收到通知。
3. 可以动态地添加或删除观察者。
主题可以动态地添加或删除观察者，这使得主题的灵活性更高。
观察者模式的缺点有：1. 如果一个观察者的更新操作比较耗时，会影响整体的性能。
2. 如果观察者和主题之间存在循环依赖的话，可能导致系统崩溃。
下面我们来通过一个例子来进一步理解观察者模式。
假设有一家电商平台，当有新的产品上架时，平台需要通知所有的用户。
这里可以将电商平台视为主题，将用户视为观察者。
具体的实现如下：首先，我们需要定义一个Subject接口，它包含了注册观察者、移除观察者和通知观察者的方法。
```javapublic interface Subject {void registerObserver(Observer observer);void removeObserver(Observer observer);void notifyObservers();}```然后，我们需要定义一个Observer接口，它包含了接收主题通知的方法。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
观察者模式
谢 谢
观察者模式
T：那也不能说明什么问题啊! ：那也不能说明什么问题啊 M：“别急，好戏还在后头呢，公司会用一个 ： 别急，好戏还在后头呢， 管理类来管理所有员工,你只是属于所有员 管理类来管理所有员工 你只是属于所有员 工之中的chPlayer这是什么玩 ： 你上面 这是什么玩 意，以前我做程序的时候好象没看到过这个 东东，是不是自己定义的？ 东东，是不是自己定义的？” M：不错，MCatchPlayer是自己定义的 ：不错， 是自己定义的 一个类，它是一个观察者，用来传递消息的， 一个类，它是一个观察者，用来传递消息的， 等会你就知道了， 等会你就知道了，你玩游戏就是通过它把你 的的名字等信息传递到老总那去的。 的的名字等信息传递到老总那去的。
观察者模式
T：“说实话，我不做程序好多天，可我还是 ： 说实话，我不做程序好多天， 难忘曾经的那些天！听到你说面这样说， 难忘曾经的那些天！听到你说面这样说，我 到是对这个软件设计方案有点兴趣了， 到是对这个软件设计方案有点兴趣了，你能 不能说详细点来听听？ 不能说详细点来听听？”
观察者模式
M：“你是一个人，用面向对象的思想来说的 ： 你是一个人， 那么你就是一个对象吧？ 话，那么你就是一个对象吧？抽象的人类对 在公司里，你作为一名员工， 象，在公司里，你作为一名员工，那我们就 计算机语言来抽象出员工这个对象 Employee,你要玩游戏，而且在玩游戏的 你要玩游戏， 你要玩游戏 时候还会被老总给逮住， 时候还会被老总给逮住，那你得去做一个 PlayGame方法吧 方法吧. 方法吧
观察者模式
M: “当他打开 时，伴随着一段优美的 当他打开CS时 Music，PlayGame函数返回 函数返回ETrue，接 ， 函数返回 ， 下来轮到EmployeeManager类上场了” 类上场了” 下来轮到 类上场了
观察者模式
M:“下面我们来看看老总(UI)类里是怎么 “下面我们来看看老总 类里是怎么 处理的，当员工(Employee)玩游戏（调 玩游戏（ 处理的，当员工 玩游戏 用了PlayGame）的时候老总是怎么得到 用了 ） 通知的。 通知的。”
观察者模式
M:“当有员工(Employee)玩游戏（调用 “当有员工 玩游戏（ 玩游戏 了PlayGame）的时候老总 ）的时候老总(UI)类就会得 类就会得 到通知。 到通知。” T：“你说得比唱得还好听，就这么几十句 ： 你说得比唱得还好听， 代码，有你说的那么神吗？我就不信， 代码，有你说的那么神吗？我就不信，好， 我去试试 M:“前面忘了说，我那同学叫张三，今年 “前面忘了说，我那同学叫张三， 23岁了。）打开了电脑，游戏启动” 岁了。）打开了电脑， 岁了。）打开了电脑 游戏启动”
观察者模式
观察者(Observer)模式定义了对象间的一 模式定义了对象间的一 观察者 对多的依赖关系， 对多的依赖关系，当一个对象的状态发生改 变时，所有依赖它的对象都能得到通知。 变时，所有依赖它的对象都能得到通知。
观察者模式
观察者模式在symbian OS c++程序中 观察者模式在 程序中
观察者模式
T：“是啊，我也这样怀疑过，因为办公室里 ： 是啊，我也这样怀疑过， 出了我，别的同事玩游戏他也知道。 出了我，别的同事玩游戏他也知道。神了 这！” M：“那他不是一个人可以监视你门多个呀？ ： 那他不是一个人可以监视你门多个呀？ 他还玩得高级呢， 也，他还玩得高级呢，还弄个一对多的关系 出来了。 出来了。而你办公室里的任何一个人玩游戏 他都能准确准时的逮住你们， 他都能准确准时的逮住你们，你们老总够强 大的哈！ 大的哈！” T：“你是不是做软件做疯了，这也能和软件 ： 你是不是做软件做疯了， 设计拉上关系？别瞎扯了，说正事吧。 设计拉上关系？别瞎扯了，说正事吧。”
观察者模式
观察者模式
--这时，老总办公室里的警报声响了，发出了信号； 这时，老总办公室里的警报声响了，发出了信号； 这时 --小张刚刚启动游戏，突然办公室门开了。进来了 小张刚刚启动游戏，突然办公室门开了。 小张刚刚启动游戏 一个“ 一个“人。 A:“张三，你胆子够大的嘛，昨天玩游戏还罚款 “张三，你胆子够大的嘛， 个大洋， 你100个大洋，你今天还敢玩？等会到我办公室去 个大洋 你今天还敢玩？ 我们聊一会！ 我们聊一会！” --估计这次我这位同学要被洗白。。。。期待被抄 估计这次我这位同学要被洗白。。。。期待被抄 估计这次我这位同学要被洗白。。。。 中ing.......
观察者模式
M：“你仔细看看我上面提到的软件设计知识点，你 ： 你仔细看看我上面提到的软件设计知识点， 们老总可以监视你们多个人， 们老总可以监视你们多个人，当你们玩游戏他就可 以准确准时的逮到你们， 以准确准时的逮到你们，用程序来说就是当你们一 玩游戏的时候就调用了PlayGame()方法吗？而 方法吗？ 玩游戏的时候就调用了 方法吗 （）方法是被监视起的 当PlayGame（）方法是被监视起的，当 （）方法是被监视起的， PlayGame（）被调用的时候就会自动的通知监 （）被调用的时候就会自动的通知监 （） 视者（你们老总），这样很明显， ），这样很明显 视者（你们老总），这样很明显，他就知道你们在 拿他的钱吃饭不给他做事， 拿他的钱吃饭不给他做事，反而在办公室里玩游戏 逮到你你就该着了。不过你也要调过头想想， 了，逮到你你就该着了。不过你也要调过头想想， 老总这样做也是有原因的， 老总这样做也是有原因的，毕竟他投资了资本出来 是想得到回报的，是吧？ 是想得到回报的，是吧？”
M类
Symbian OS中，M类通常定义为回调 中 类通常定义为回调 (callback)接口或监听器 接口或监听器(observer) 接口或监听器 接口
乐成数字通信学院
观察者模式
前言
上班玩游戏，老总是怎么知道的 上班玩游戏，老总是怎么知道的?
观察者模式
注：以下反出现“同学”的地方都使用“T” 以下反出现“同学”的地方都使用“ ” 代替，我自己使用“ ”代替，老总“ ” 代替，我自己使用“M”代替，老总“A”。 前些天一个同学告诉我:“ 前些天一个同学告诉我:“我上班的时候玩 游戏,怎么老总知道 怎么老总知道.难不成他在办公室里装 游戏 怎么老总知道 难不成他在办公室里装 有监视器.” 有监视器 ” T: “那老总是怎么知道我玩游戏的呢 ” 那老总是怎么知道我玩游戏的呢?” M：“这个问题还得好好研究下，或许他还 ： 这个问题还得好好研究下， 可能真的是在办公室的某处装有摄像头监视 哈哈！ 呢，哈哈！”
Symbian
观察者模式(M类) 观察者模式 类
什么是M 什么是M类
M类是一个抽象接口类，也叫混合类，定义了抽象 类是一个抽象接口类，也叫混合类， 的协议或接口，其具体的处理由派生类来完成， 的协议或接口，其具体的处理由派生类来完成，所 类有如下特点： 以M类有如下特点： (1) 它们不含有任何成员数据 它们不应该包括析构或构造函数， (2) 它们不应该包括析构或构造函数，以及重载 描述符 M类通常包括一系列定义抽象接口的纯虚函数 类通常包括一系列定义抽象接口的纯虚函数， (3) M类通常包括一系列定义抽象接口的纯虚函数， 有些M类可能提供成员函数的处理（ 有些M类可能提供成员函数的处理（尽管有上面的 约束） 约束） M类是symbian平台上唯一使用多重继承的类 类是symbian (4) M类是symbian平台上唯一使用多重继承的类