精华内容
下载资源
问答
  • 观察者模式(Observer Pattern)(有时又被称为模型(Model)-视图(View)模式、源-收听者(Listener)模式或从属者模式)是软件设计模式的一种。在此种模式中,一个目标物件管理所有相依于它的观察者物件,并且在它...

    0x01.简述

    • 观察者模式(Observer Pattern)(有时又被称为模型(Model)-视图(View)模式、源-收听者(Listener)模式或从属者模式)是软件设计模式的一种。在此种模式中,一个目标物件管理所有相依于它的观察者物件,并且在它本身的状态改变时主动发出通知。这通常透过呼叫各观察者所提供的方法来实现。此种模式通常被用来实现事件处理系统。(百度百科)
    • 当对象间存在一对多关系时,可以使用观察者模式。
    • 例如,当一个对象被修改时,则会自动通知它的依赖对象。
    • 观察者模式属于行为型模式

    0x02.理解观察者模式

    一个最为经典的例子:老师与同学的例子。

    场景:

    一个班的老师有10个学生,老师知道这10个学生的所有信息,老师讲课,学生都能听到,老师点名,对应的同学能起来回答问题。

    把这一场景简单化:

    • 其实就是满足了这样的关系:

      • 老师拥有学生们的信息。
      • 学生可以听到老师讲课和点名。

    这个例子中的观察者模式:

    • 老师与学生们是一对多的关系。
    • 当老师讲课或者点名时,同学们能做出响应(当一个对象被修改时,则会自动通知它的依赖对象。
    • 在这个例子中,同学们就是观察者,老师就是被观察者。观察者观察被观察者的行为,并通过这些行为做出响应。
      具体的关系可以参考下图:

    在这里插入图片描述

    • 将其抽象化,就是如下关系:

    在这里插入图片描述

    0x03.上述例子的实际代码实现

    用代码将这一关系表示出来更容易理解!

    • 总结一下上面的关系,明白我们代码需要做哪些事情:

      • (1)一个老师有10名学生。
      • (2)老师拥有学生的信息。
      • (3)老师点名,学生答到。
    • 接下来具体实现一下:

    Person类:(父类)

    • 包含老师和学生的公共属性。
    public class Person {
        private String name;
        private Integer age;
    
        public String getName() {
            return name;
        }
    
        public void setName(String name) {
            this.name = name;
        }
    
        public Integer getAge() {
            return age;
        }
    
        public void setAge(Integer age) {
            this.age = age;
        }
    }
    

    Student类:

    • 有答到的方法。
    public class Student extends Person {
    
        public void daDao(){
            System.out.println(super.getName()+":到!");
        }
    
    }
    

    Teacher类:

    • 包含学生的信息。
    • 包含一个点到的方法。
    public class Teacher extends Person{
        //老师保留学生的信息
        private List<Student> students = new ArrayList<Student>();
    
        public void Dao() throws InterruptedException {
            while(true){
                int radom = (int)(Math.random()*10);
                Student stu=students.get(radom);
                System.out.println(stu.getName()+" 到了吗?");
                stu.daDao();
                Thread.sleep(3000);
            }
        }
        public void addStu(Student stu){
            this.students.add(stu);
        }
    }
    

    Test:

    public class Test {
        public static void main(String[] args) throws InterruptedException {
            Teacher teacher=new Teacher();
            teacher.setName("王老师");
            teacher.setAge(27);
            for(int i=0;i<10;i++){
                Student stu=new Student();
                stu.setName("同学"+(i+1));
                stu.setAge(18);
                teacher.addStu(stu);
            }
            teacher.Dao();
        }
    }
    

    效果展示:

    在这里插入图片描述

    0x04.回顾代码–再反思

    从我们的代码中可以看出,实现这个小功能的核心代码是:

    • 在Teacher类中存储了所有的Student的信息,这样,只要老师点到,就能调用学生的签到方法。

    其实整个观察者模式中,最为重要的就是:当一个对象被修改时,则会自动通知它的依赖对象。

    0x05.清楚优势

    观察者模式主要用于一对多的关系,它在实际应用中的优势有:

    • (1)降低了目标与观察者之间的耦合关系,将本来的耦合关系变成了抽象耦合关系。
    • (2)目标与观察者之间建立了一套触发机制。

    0x06.明白劣势

    • (1)目标与观察者之间的依赖关系并没有完全解除,并且有可能出现循环引用。
    • (2)当观察者直接或间接对象很多时,通知的发布会花费很多时间,影响程序执行的效率。
    • (3)观察者模式仅仅只是知道观察目标发生了变化,无法让观察者知道所观察的目标对象是怎么发生变化的。

    0x07.主要应用

    Spring MVC的核心处理机制:

    • 在Spring MVC的处理机制中,其实就使用到了观察者模式:
    • 核心控制器就是被观察者,其余的对象就是观察者,当核心控制器发生改变(比如得到Handler),相应的对象就会收到通知,也做出相应的改变。
      在这里插入图片描述

    感谢@Mr.ml大佬的指导

    展开全文
  • 观察者模式

    千次阅读 2017-04-13 20:27:28
    观察者模式

    这篇博客主要总结一下观察者模式。


    观察者模式应该算是众多设计模式中,
    应用比较广,同时也比较好理解的模式了。

    因此这里直接给出它的定义:
    观察者模式定义了对象之间的一对多依赖,
    这样一来,当一个对象改变状态时,它的所有依赖者都会收到通知并自动更新。

    SouthEast

    观察者模式的思想基本上可以用上图来说明。

    有状态的对象将作为消息发布者,
    负责将状态变化的信息通知给观察者们。

    如图所示:
    加入了订阅组的用户就是消息发布者的观察者,
    它们会在必要时收到通知消息。

    没有加入订阅组的用户4,不会收到通知信息。

    用户可以自由的加入和离开订阅组。

    这个过程,就像你在新闻APP中订阅某个专题一样。
    如果你订阅了该专题,
    那么有该专题的新闻出现时,就会主动推送给你。
    如果某天你对该专题没兴趣了,
    就可以取消订阅,此时就不会收到任何推送新闻了。


    接下来,我们看看观察者模式相关的类图:
    SouthEast

    如上图所示,主题只需要知道观察者实现了Observer接口,而不需要知道其它的细节。
    因此实际的主题对象,例如图中的ConcreteSubject对象,只需要将观察者当作Observer保存。

    同理,观察者也不需要知道主题的实现细节,只需要知道主题实现了Subject接口。
    通过Subject中的registerObserver接口,观察者可以将自己注册到主题;
    通过removeObserver接口,观察者可以取消对主题的关注。

    当主题发现状态改变时,就可以调用notifyObserver方法,调用保存的所有观察者的update函数。

    此外,主题对象还可以提供getState和setState方法,供其它对象主动获取或设置主题的状态。

    通过上图可以看出,整个观察者模式提供了一种松耦合的设计。
    主题和观察者之间可以交互,但不需要清楚彼此的细节。
    只要遵循它们之间定义的接口,那么改变主题或观察者其中一方,并不会影响另一方。


    最后,我们来看看Android源码中使用观察者模式的例子。

    Android中使用观察者模式的地方很多,此处我们以RIL的通知框架为例。
    SouthEast

    如图所示,RIL接收modem上报的信息,作为整个通知框架的消息发布者,即主题。
    RIL继承BaseCommands类,后者实现了CommandsInterface接口。

    CommandsInterface接口中定义了许多注册、反注册函数,这里以RadioState相关的函数为例。
    ServiceStateTracker作为观察者,需要将自己的Handler等参数注册到主题中。

    主题将利用利用这些参数构造出Registrant对象,
    并保存到BaseCommands中的mRadioStateChangedRegistrants中。

    当RadioState发生变化时,BaseCommands就会通知mRadioStateChangedRegistrants中的所有Registrant。
    Registrant就会利用自身的Handler发送消息给实际的观察者ServiceStateTracker。

    RIL通知框架的类图与上文提到的观察者模式类图基本一致,
    唯一的区别是观察者并没有继承接口对象,而是将Handler注册到主题中。
    考虑到Handler在Android中的普及程度,实质上这也可以看作一种针对“接口”的编程。

    展开全文
  • 观察者设计模式

    万次阅读 2019-09-23 16:39:10
    观察者设计模式 用订阅和发布来理解更好,我想了一下是的 为什么呢?因为监听器这个名词听起来是一个主动的,可实际监听器是一个被动的玩意 比如我们事件源发布一个事件,然后监听器订阅了这个事件就能做出动作。 ...

    观察者设计模式

    用订阅和发布来理解更好,我想了一下是的
    为什么呢?因为监听器这个名词听起来是一个主动的,可实际监听器是一个被动的玩意
    比如我们事件源发布一个事件,然后监听器订阅了这个事件就能做出动作。
    里面涉及到三个对象,事件源,事件、监听器,大家好好理解一下
    

    特点:

    • 被观察者持有监听的观察者的引用
    • 被观察者支持增加和删除观察者
    • 被观察者主题状态改变,通知观察者
    • 下面开始模拟观察者设计模式
    • 版本1:
    • 在这里插入图片描述

    版本1模拟的观察者设计模式,是采用了观察者持有被观察者的实例的方式。该方式存在的问题,也是比较明显:

    观察者需要不断的执行,监听被观察者的状态。性能耗费比较大。

    • 版本2:
    • 在这里插入图片描述

    版本2模拟的观察者设计模式,是采用了被观察者持有观察者的实例的方式。该方式存在的问题,也是比较明显:

    被观察者强制依赖了观察者,耦合度比较高。

    • 版本3:
    • 在这里插入图片描述

    版本3模拟的观察者设计模式,有了几个方面的提升:

    1. 被观察者持有监听的观察者的引用
    2. 被观察者支持增加观察者
    3. 观察者已通过MovieListener接口抽象,与被观察者的耦合性降低了。

    观察者设计模式的特点:

    • 被观察者持有监听的观察者的引用
    • 被观察者支持增加和删除观察者
    • 被观察者主题状态改变,通知观察者

    总结:
    观察者设计模式 用 “订阅”和“发布“”来理解更好
    为什么呢?因为监听器这个名词听起来是一个主动的,可实际监听器是一个被动的玩意
    比如我们事件源发布一个事件,然后监听器订阅了这个事件就能做出动作。
    里面涉及到三个对象,事件源,事件、监听器,好好理解一下。

    • JDK的观察者设计实现:
    • 在这里插入图片描述

    JDK中观察者的实现:

    • java.util.Observable 这是一个类,继承,被观察者
    • java.util.Observer 这是一个接口,实现,观察者

    观察者impl Observer重写update方法:

    • 当被观察者发生变化,收到通知进行具体的管理
    • 可以随时取消
    • Spring中实现:
    • 在这里插入图片描述

    Spring中的Events

    事件通过org.springframework.context.ApplicationEvent实例来表示。这个抽象类继承扩展了java.util.EventObject,可以使用EventObject中的getSource方法,我们可以很容易地获得所发生的给定事件的对象。这里,事件存在两种类型

    1. 与应用程序上下文相关联

      所有这种类型的事件都继承自org.springframework.context.event.ApplicationContextEvent类。
      它们应用于由org.springframework.context.ApplicationContext引发的事件(其构造函数传入的是ApplicationContext类型的参数)。

      这样,我们就可以直接通过应用程序上下文的生命周期来得到所发生的事件:

      1. 在上下文启动时被启动ContextStartedEvent
      2. 当它停止时启动ContextStoppedEvent
      3. 当上下文被刷新时产生ContextRefreshedEvent
      4. 最后在上下文关闭时产生ContextClosedEvent
    2. 与request 请求相关联
      org.springframework.web.context.support.RequestHandledEvent实例来表示,当在ApplicationContext中处理请求时,它们被引发。

    Spring如何将事件分配给专门的监听器?

    这个过程由事件广播器来实现,由org.springframework.context.event.ApplicationEventMulticaster接口的实现表示。此接口定义了3种方法

    (1)addApplicationListener():添加新的监听器

    1. 定义了两种方法来添加新的监听器:addApplicationListener(ApplicationListener<?> listener)和addApplicationListenerBean(String listenerBeanName)
    2. 当监听器对象已知时,可以应用第一个。如果使用第二个,我们需要将bean name 得到listener对象(依赖查找DL),然后再将其添加到listener列表中

    (2)removeApplicationListenerBean(String listenerBeanName):删除监听器

    1. 通过传递对象来删除一个监听器(removeApplicationListener(ApplicationListener<?> listener)或通过传递bean名称。
    2. 第三种方法,removeAllListeners()用来删除所有已注册的监听器。

    (3)multicastEvent(ApplicationEvent event):将事件发送到已注册的监听器

    展开全文
  • 大话设计模式(五)观察者模式

    万次阅读 2016-09-05 17:38:20
    大话设计模式(五)观察者模式概念 在阎宏博士的《JAVA与模式》一书中开头是这样描述观察者(Observer)模式的: 观察者模式是对象的行为模式,又叫发布-订阅(Publish/Subscribe)模式、模型-视图(Model/View)模式、源-...

    大话设计模式(五)观察者模式

    概念

      在阎宏博士的《JAVA与模式》一书中开头是这样描述观察者(Observer)模式的:

      观察者模式是对象的行为模式,又叫发布-订阅(Publish/Subscribe)模式、模型-视图(Model/View)模式、源-监听器(Source/Listener)模式或从属者(Dependents)模式。

         观察者模式定义了一种一对多的依赖关系,让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生变化时,会通知所有观察者对象,使它们能够自动更新自己。

    结构

         一个软件系统里面包含了各种对象,就像一片欣欣向荣的森林充满了各种生物一样。在一片森林中,各种生物彼此依赖和约束,形成一个个生物链。一种生物的状态变化会造成其他一些生物的相应行动,每一个生物都处于别的生物的互动之中。

         同样,一个软件系统常常要求在某一个对象的状态发生变化的时候,某些其他的对象做出相应的改变。做到这一点的设计方案有很多,但是为了使系统能够易于复用,应该选择低耦合度的设计方案。减少对象之间的耦合有利于系统的复用,但是同时设计师需要使这些低耦合度的对象之间能够维持行动的协调一致,保证高度的协作。观察者模式是满足这一要求的各种设计方案中最重要的一种。

         下面以一个简单的示意性实现为例,讨论观察者模式的结构。

    所涉及的角色

      抽象主题(Subject)角色:抽象主题角色把所有对观察者对象的引用保存在一个聚集(比如ArrayList对象)里,每个主题都可以有任何数量的观察者。抽象主题提供一个接口,可以增加和删除观察者对象,抽象主题角色又叫做抽象被观察者(Observable)角色。

     具体主题(ConcreteSubject)角色:将有关状态存入具体观察者对象;在具体主题的内部状态改变时,给所有登记过的观察者发出通知。具体主题角色又叫做具体被观察者(Concrete Observable)角色。

     抽象观察者(Observer)角色:为所有的具体观察者定义一个接口,在得到主题的通知时更新自己,这个接口叫做更新接口。

     具体观察者(ConcreteObserver)角色:存储与主题的状态自恰的状态。具体观察者角色实现抽象观察者角色所要求的更新接口,以便使本身的状态与主题的状态相协调。如果需要,具体观察者角色可以保持一个指向具体主题对象的引用。

    推模式源代码

    抽象主题角色类

     

     

    // 主题角色类接口
    public interface Subject {
     
    // 添加订阅者
    public void attach(Observer observer);
    // 移除订阅者
    public void detach(Observer observer);
    // 发布者通知所有订阅者--推模式
    public void nodifyObserversByPush(String newState);
    }

     

    具体主题角色类

     

    //具体主题角色类
    public class ConcreteSubject implements Subject{
     
        //用来保存注册的观察者对象
        private List<Observer> list = new ArrayList<Observer>();
        
        private String name = "SHQ";
        private int age = 27;
        
        public String getName() {
    return name;
    }
     
    public int getAge() {
    return age;
    }
     
    /**
         * 注册观察者对象
         * @param observer    观察者对象
         */
        @Override
        public void attach(Observer observer){
            list.add(observer);
            System.out.println("Attached an observer");
        }
        
        /**
         * 删除观察者对象
         * @param observer    观察者对象
         */
        @Override
        public void detach(Observer observer){
            list.remove(observer);
        }
        /**
         * 通知所有注册的观察者对象
         */
        @Override
        public void nodifyObserversByPush(String newState){
            for(Observer observer : list){
                observer.updateByPush(newState);
            }
        }    
    }

     

    抽象观察者角色类

     

    //抽象观察者角色类
    public interface Observer {
        /**
         * 更新接口--推模式
         * @param state    更新的状态
         */
        public void updateByPush(String state);
    }

     

    具体观察者角色类

     

    // 具体观察者角色类
    public class ConcreteObserver implements Observer {
     
        // 观察者的状态
        private String observerState;
        
        @Override
        public void updateByPush(String state) {
            /**
             * 更新观察者的状态,使其与目标的状态保持一致
             */
            observerState = state;
            System.out.println("状态为:" + observerState);
        }    
    }

     

    客户端类

     

    //客户端类
    public class Client {
        public static void main(String[] args) {
            //创建主题对象
            ConcreteSubject subject = new ConcreteSubject();
            //创建观察者对象
            Observer observer1 = new ConcreteObserver();       
            //将观察者对象登记到主题对象上
            subject.attach(observer1);
            //改变主题对象的状态--推模式
            subject.nodifyObserversByPush("new state");
        }
    }

     

    运行结果如下:

      在运行时,这个客户端首先创建了具体主题类的实例,以及一个观察者对象。然后,它调用主题对象的attach()方法,将这个观察者对象向主题对象登记,也就是将它加入到主题对象的聚集中去。

      这时,客户端调用主题的change()方法,改变了主题对象的内部状态。主题对象在状态发生变化时,调用超类的notifyObservers()方法,通知所有登记过的观察者对象。

    推模型和拉模型

        在观察者模式中,又分为推模型和拉模型两种方式。

    推模型

     主题对象向观察者推送主题的详细信息,不管观察者是否需要,推送的信息通常是主题对象的全部或部分数据。

    拉模型

     主题对象在通知观察者的时候,只传递少量信息。如果观察者需要更具体的信息,由观察者主动到主题对象中获取,相当于是观察者从主题对象中拉数据。一般这种模型的实现中,会把主题对象自身通过update()方法传递给观察者,这样在观察者需要获取数据的时候,就可以通过这个引用来获取了。

      根据上面的描述,发现前面的例子就是典型的推模型,下面给出一个拉模型的实例。

    拉模型的抽象观察者类

     

        拉模型通常都是把主题对象当做参数传递。

     

    //抽象观察者角色类
    public interface Observer {
        // 拉模式
        public void updateByPull(Subject subject);
    }

     

    拉模型的具体观察者类

     

    // 具体观察者角色类
    public class ConcreteObserver implements Observer {
     
        // 观察者的状态
        private String observerState;
        
    @Override
    public void updateByPull(Subject subject) {
    observerState = ((ConcreteSubject)subject).getName();
    System.out.println("状态为:" + observerState);
    }
    }

     

    拉模型的抽象主题类

     拉模型的抽象主题类主要的改变是nodifyObservers()方法。在循环通知观察者的时候,也就是循环调用观察者的update()方法的时候,传入的参数不同了。

     

    // 主题角色类接口
    public interface Subject {
     
    // 添加订阅者
    public void attach(Observer observer);
    // 移除订阅者
    public void detach(Observer observer);
    // 发布者通知所有订阅者--拉模式
    public void nodifyObserversByPull();
    }

     

    拉模型的具体主题类

      跟推模型相比,有一点变化,就是调用通知观察者的方法的时候,不需要传入参数了。

     

    //具体主题角色类
    public class ConcreteSubject implements Subject{
     
        //用来保存注册的观察者对象
        private List<Observer> list = new ArrayList<Observer>();
        
        private String name = "SHQ";
        private int age = 27;
        
        public String getName() {
    return name;
    }
     
    public int getAge() {
    return age;
    }
     
    /**
         * 注册观察者对象
         * @param observer    观察者对象
         */
        @Override
        public void attach(Observer observer){
            list.add(observer);
            System.out.println("Attached an observer");
        }
        
        /**
         * 删除观察者对象
         * @param observer    观察者对象
         */
        @Override
        public void detach(Observer observer){
            list.remove(observer);
        }
     
    @Override
    public void nodifyObserversByPull() {
            for(Observer observer : list){
                observer.updateByPull(this);
            }
    }   
    }

     

    两种模式的比较

      推模型是假定主题对象知道观察者需要的数据;而拉模型是主题对象不知道观察者具体需要什么数据,没有办法的情况下,干脆把自身传递给观察者,让观察者自己去按需要取值。

     推模型可能会使得观察者对象难以复用,因为观察者的update()方法是按需定义的参数,可能无法兼顾没有考虑到的使用情况。这就意味着出现新情况的时候,就可能提供新的update()方法,或者是干脆重新实现观察者;而拉模型就不会造成这样的情况,因为拉模型下,update()方法的参数是主题对象本身,这基本上是主题对象能传递的最大数据集合了,基本上可以适应各种情况的需要。

        这两种模式的使用,取决于系统设计时的需要。如果目标角色比较复杂,并且观察者角色进行更新时必须得到一些具体变化的信息,则“推模式”比较合适。如果目标角色比较简单,则“拉模式”就很合适啦。

    观察者模式的应用场景

        1、对一个对象状态的更新,需要其他对象同步更新,而且其他对象的数量动态可变。

        2、对象仅需要将自己的更新通知给其他对象而不需要知道其他对象的细节。

    观察者模式的优点

        1、Subject和Observer之间是松偶合的,分别可以各自独立改变(它把观察者与被观察者分离,并将二者间的关系通过抽象观察者和抽象被观察者联系在一起,当一方发生变化时不会影响另一方的执行,从而降低了程序的耦合。)。

        2、可以支持多种不同的具体观察者实现,有利于程序的扩展。

        3、观察者的数目是可变的,主题可以实现动态的增加或移除观察者对象。

        3、Subject在发送广播通知的时候,无须指定具体的Observer,Observer可以自己决定是否要订阅Subject的通知。

        4、遵守大部分GRASP原则和常用设计原则,高内聚、低偶合。

        5、被观察者在自身状态发生变化时,会主动通知观察者,如果不是被观察者主动通知,那就需要观察者通过定时任务的方式来监控被观察者的状态是否发生变化,被观察者主动通知的方式要比观察者定时监控方式性能更高。

    观察者模式的缺陷

        1、松偶合导致代码关系不明显,有时可能难以理解。(废话)

        2、如果一个Subject被大量Observer订阅的话,在广播通知的时候可能会有效率问题。(毕竟只是简单的遍历)。

        3、观察者模式是一种常用的触发机制,它形成一条触发链,依次对各个观察者的方法进行处理。但同时,这也算是观察者模式一个缺点,由于是链式触发,当观察者比较多的时候,性能问题是比较令人担忧的。并且,在链式结构中,比较容易出现循环引用的错误,造成系统假死。

    美文美图

    展开全文
  • Android 观察者与被观察者

    千次阅读 2016-06-25 16:34:54
    最近正好闲来无事,正好做完项目,由于里面用到了RxJava,有些许体会,但今天我在这儿,并不会讲RXjava,任何...废话不说了,下面我们就来讲解观察者与被观察者. Observer 观察者,说白了就是观察别人.(你这不是,废话吗!) Obs
  • JAVA设计模式--观察者模式

    万次阅读 2016-06-18 20:43:31
    观察者(Observer)模式是行为模式之一,它的作用是当一个被观察对象的状态发生变化时,能够自动通知相关的观察者对象,自动更新观察者对象中被观察对象的状态。它提供给关联对象一种同步通信的手段,使某个对象与依赖...
  • 设计模式(五)观察者模式

    万次阅读 多人点赞 2016-03-02 17:41:50
    观察者模式(又被称为发布-订阅(Publish/Subscribe)模式,它定义了一种一对多的依赖关系,让多个观察者对象同时监听莫一个主题对象。这个主题对象在状态变化时,会通知所有的观察者对象,使他们能够自动更新自己。
  • C++ 观察者模式

    千次阅读 多人点赞 2017-03-13 19:33:34
    观察者模式(Observer Pattern),定义了对象间的一对多的依赖关系,让多个观察者对象同时监听某一个主题对象(被观察者)。当主题对象的状态发生更改时,会通知所有观察者,让它们能够自动更新。 简述 背景 模式...
  • Java设计模式之观察者模式

    万次阅读 多人点赞 2019-01-09 11:16:17
    文章目录概念自己实现一个观察者模式使用Java自带的观察者模式类实现 概念 在对象之间定义了一对多的依赖,这样一来,当一个对象改变状态,依赖它的对象会收到通知并自动更新。 观察者模式主要有两个角色 Subject...
  • 行为型-观察者模式

    千次阅读 2021-04-12 18:15:42
    观察者注册到被观察者上,当观察者发生变动, 去通知观察者(监听者) public class ObserverPatternDemo { public static void main(String[] args) { Subject subject = new Subject(0); Observer ...
  • 今天打开《重构和模式》...然后拿起一本《header first 设计模式》,才觉得我的疑问是对的,如果每个观察者里的被观察者都是新建的,那么它只能有一个观察者。 应该通过构造函数将被观察者作为参数传进去,参考如图:

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 55,386
精华内容 22,154
关键字:

观察者