【设计模式专题】观察者模式实战详细分析

简介: 【设计模式专题】观察者模式实战详细分析

正文


一 什么是观察者模式


定义对象间一种一对多的依赖关系,使得每当一个对象改变状态,则所有依赖于它的对象都会得到通知,并自动更新。


新手经常会把观察者模式经常与发布订阅模式,其实二者还是有一些区别的,


二 观察者模式与发布订阅模式的区别


  • 观察者模式主要的使用场景是一对多的状态,且需要知道通知的对象是谁。
  • 发布订阅模式的主要使用场景是一对多或者多对多的状态,且不需要知道通知的对象也就是消费者是谁。
  • 观察者模式属于Gang of Four 提出的23中设计模式中的一种,发布订阅模式并不属于其中的一种而是一种软件设计理念。
  • 观察者模式耦合度较高,因为观察者模式中目标的只有一个,观察者需要知道目标的所有行为。
  • 发布订阅的耦合度较低,而发布订阅的发布者可以有多个,订阅者不需要知道发布者是谁,只需要关心发布的内容。


三 编写demo案例


比如今天是周一,Leader需要公司里的员工加班,员工分别有Jack、Mark,然而每个人对加不加班是有自己的看法和行为的,这时就可以把Leader作为目标/主题,Jack、Mark做为观察者,观察者需要根据目标的指令来做出对应的行为。


一般观察者模式有4个角色,分别为:抽象目标类、具体目标类、抽象观察类、具体观察类。


代码实现如下:


抽象目标类 :MySubject

一 什么是观察者模式
定义对象间一种一对多的依赖关系,使得每当一个对象改变状态,则所有依赖于它的对象都会得到通知,并自动更新。
新手经常会把观察者模式经常与发布订阅模式,其实二者还是有一些区别的,
二 观察者模式与发布订阅模式的区别
观察者模式主要的使用场景是一对多的状态,且需要知道通知的对象是谁。
发布订阅模式的主要使用场景是一对多或者多对多的状态,且不需要知道通知的对象也就是消费者是谁。
观察者模式属于Gang of Four 提出的23中设计模式中的一种,发布订阅模式并不属于其中的一种而是一种软件设计理念。
观察者模式耦合度较高,因为观察者模式中目标的只有一个,观察者需要知道目标的所有行为。
发布订阅的耦合度较低,而发布订阅的发布者可以有多个,订阅者不需要知道发布者是谁,只需要关心发布的内容。
三 编写demo案例
比如今天是周一,Leader需要公司里的员工加班,员工分别有Jack、Mark,然而每个人对加不加班是有自己的看法和行为的,这时就可以把Leader作为目标/主题,Jack、Mark做为观察者,观察者需要根据目标的指令来做出对应的行为。
一般观察者模式有4个角色,分别为:抽象目标类、具体目标类、抽象观察类、具体观察类。
代码实现如下:
抽象目标类 :MySubject
————————————————
版权声明:本文为CSDN博主「掂掂三生有幸」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/weixin_42469135/article/details/12641330

具体目标类 :Leader

/**
 * @author liuy 抽象观察者类
 * @create 2022-08-18-13:05
 */
public interface MyObserver {
    void response(int state); //抽象响应方法
}

具体观察者类一:Jack

/**
 * @author liuy 具体观察者类
 * @create 2022-08-18-13:05
 */
public class Jack implements MyObserver {
    @Override
    public void response(int state) {
        String name = "Jack:";
        if(state ==1){
            System.out.println(name + "需要加班,开摆!");
        }else {
            System.out.println(name + "哈哈哈,不加班就可以回家打游戏了");
        }
    }
}

具体观察者类二:Mark

/**
 * @author liuy 具体观察者类
 * @create 2022-08-18-13:05
 */
public class Mark implements MyObserver {
    @Override
    public void response(int state) {
        String name = "Mark:";
        if(state ==1){
        System.out.println(name + "我爱加班,因为有加班费");
        }else {
            System.out.println(name + "呜呜呜,没加班费拿了");
        }
    }
}

现在基本的观察者模式已经实现了,现在开始测试。

/**
 * @author liuy 客户端测试
 * @create 2022-08-18-13:05
 */
public class Client {
    public static void main(String[] args) {
        MySubject subject = new Leader();
        MyObserver obs1, obs2;
        obs1 = new Jack();
        obs2 = new Mark();
        subject.attach(obs1);
        subject.attach(obs2);
//        subject.detach(ObserverEnum.Dog.getMyObserver());
        System.out.println("===================== 第一天 =======================");
        //1代表需要加班,2代表不加班
        System.out.println("Leader:今天所有人都要加班!");
        subject.push(1);
        System.out.println("===================== 第二天 ====================");
        //1代表需要加班,2代表不加班
        System.out.println("Leader:今天大家不用加班了!");
        subject.push(2);
    }
}

测试结果


0000.png


相信有一些小伙伴已经发现了,如果像测试类中的写法,每次发送消息的时候都需要new对应的对象然后添加到观察者集合中,这样很不方便


我们可以使用观察者模式+工厂模式来解决这个问题。


四 优化demo案例 观察者模式+工厂模式


创建观察者工厂枚举类:ObserverEnum

/**
 * @Author liuy
 * @Description 观察者工厂枚举类
 * @Date 2022/8/18 14:55
 * @Version 1.0
 */
public enum ObserverEnum {
    Mouse(new Jack()),
    Dog(new Mark()),
    ;
    ObserverEnum(MyObserver myObserver) {
        this.myObserver = myObserver;
    }
    private  MyObserver  myObserver;
    public MyObserver getMyObserver() {
        return myObserver;
    }
    public void setMyObserver(MyObserver myObserver) {
        this.myObserver = myObserver;
    }
    public static List<MyObserver> getObservers(){
        return Arrays.stream(ObserverEnum.values()).map(ObserverEnum::getMyObserver).collect(Collectors.toList());
    }
}

然后只需要修改抽象目标类中的观察者集合成员变量:observers

import java.util.List;
/**
 * @author liuy 抽象目标类
 * @create 2022-08-18-13:05
 */
public abstract class MySubject {
    //所有观察者集合
    //旧 protected List<MyObserver> observers = new ArrayList<>() ;
    protected List<MyObserver> observers = ObserverEnum.getObservers();
    //注册方法
    public void attach(MyObserver observer){
        observers.add(observer);
    }
    //注销方法
    public void detach(MyObserver observer){
        observers.remove(observer);
    }
    public abstract void push(int state); //抽象通知方法
}

测试

/**
 * @author liuy 客户端测试
 * @create 2022-08-18-13:05
 */
public class Client {
    public static void main(String[] args) {
        MySubject subject = new Leader();
        System.out.println("===================== 第一天 =======================");
        //1代表需要加班,2代表不加班
        System.out.println("Leader:今天所有人都要加班!");
        subject.push(1);
        System.out.println("===================== 第二天 ====================");
        //1代表需要加班,2代表不加班
        System.out.println("Leader:今天大家不用加班了!");
        subject.push(2);
    }
}

000.png


五 优缺点


主要优点

(1)观察者模式可以实现表示层和数据逻辑层的分离,定义了稳定的消息传递机制,并抽象了更新接口,使得可以有各种各样的表示层充当具体的观察者角色。


(2)观察者模式在观察目标和观察者之间建立一个抽象的耦合。观察者对象只需要维持一个抽象观察者的集合,无需了解其具体观察者。


(3)观察者模式支持广播通信,观察目标会向所有已注册的观察者发送通知,降低了一对多系统的设计难度。


(4)观察者模式满足开闭原则的要求,增加新的具体观察者无须修改原有的系统代码。


主要缺点

(1)如果一个观察目标对象有很多的直接观察者和间接观察者,那么所有的观察者接收到消息会耗费大量的时间。


(2)如果观察者和被观察者之间存在循环依赖,那么观察目标会触发它们之间进行循环调用,可能导致系统崩溃。


(3)观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的,而仅仅只是知道目标观察对象发生了变化


相关文章
|
14天前
|
设计模式 存储 缓存
「全网最细 + 实战源码案例」设计模式——享元模式
享元模式(Flyweight Pattern)是一种结构型设计模式,旨在减少大量相似对象的内存消耗。通过分离对象的内部状态(可共享、不变)和外部状态(依赖环境、变化),它有效减少了内存使用。适用于存在大量相似对象且需节省内存的场景。模式优点包括节省内存和提高性能,但会增加系统复杂性。实现时需将对象成员变量拆分为内在和外在状态,并通过工厂类管理享元对象。
147 83
|
10天前
|
设计模式 存储 算法
「全网最细 + 实战源码案例」设计模式——命令模式
命令模式(Command Pattern)是一种行为型设计模式,将请求封装成独立对象,从而解耦请求方与接收方。其核心结构包括:Command(命令接口)、ConcreteCommand(具体命令)、Receiver(接收者)和Invoker(调用者)。通过这种方式,命令的执行、撤销、排队等操作更易扩展和灵活。 适用场景: 1. 参数化对象以操作。 2. 操作放入队列或远程执行。 3. 实现回滚功能。 4. 解耦调用者与接收者。 优点: - 遵循单一职责和开闭原则。 - 支持命令组合和延迟执行。 - 可实现撤销、恢复功能。 缺点: - 增加复杂性和类数量。
48 14
「全网最细 + 实战源码案例」设计模式——命令模式
|
10天前
|
设计模式 存储 Java
「全网最细 + 实战源码案例」设计模式——责任链模式
责任链模式(Chain of Responsibility Pattern)是一种行为型设计模式,允许将请求沿着处理者链进行发送。每个处理者可以处理请求或将其传递给下一个处理者,从而实现解耦和灵活性。其结构包括抽象处理者(Handler)、具体处理者(ConcreteHandler)和客户端(Client)。适用于不同方式处理不同种类请求、按顺序执行多个处理者、以及运行时改变处理者及其顺序的场景。典型应用包括日志处理、Java Web过滤器、权限认证等。
47 13
「全网最细 + 实战源码案例」设计模式——责任链模式
|
1月前
|
设计模式 缓存 应用服务中间件
「全网最细 + 实战源码案例」设计模式——外观模式
外观模式(Facade Pattern)是一种结构型设计模式,旨在为复杂的子系统提供一个统一且简化的接口。通过封装多个子系统的复杂性,外观模式使外部调用更加简单、易用。例如,在智能家居系统中,外观类可以同时控制空调、灯光和电视的开关,而用户只需发出一个指令即可。
140 69
|
12天前
|
设计模式 算法 开发者
「全网最细 + 实战源码案例」设计模式——策略模式
策略模式(Strategy Pattern)是一种行为型设计模式,用于定义一系列可替换的算法或行为,并将它们封装成独立的类。通过上下文持有策略对象,在运行时动态切换算法,提高代码的可维护性和扩展性。适用于需要动态切换算法、避免条件语句、经常扩展算法或保持算法独立性的场景。优点包括符合开闭原则、运行时切换算法、解耦上下文与策略实现、减少条件判断;缺点是增加类数量和策略切换成本。示例中通过定义抽象策略接口和具体策略类,结合上下文类实现动态算法选择。
47 8
「全网最细 + 实战源码案例」设计模式——策略模式
|
12天前
|
设计模式 SQL 算法
「全网最细 + 实战源码案例」设计模式——模板方法模式
模板方法模式是一种行为型设计模式,定义了算法的骨架并在父类中实现不变部分,将可变部分延迟到子类实现。通过这种方式,它避免了代码重复,提高了复用性和扩展性。具体步骤由抽象类定义,子类实现特定逻辑。适用于框架设计、工作流和相似算法结构的场景。优点包括代码复用和符合开闭原则,缺点是可能违反里氏替换原则且灵活性较低。
60 7
「全网最细 + 实战源码案例」设计模式——模板方法模式
|
24天前
|
设计模式
「全网最细 + 实战源码案例」设计模式——模式扩展(配置工厂)
该设计通过配置文件和反射机制动态选择具体工厂,减少硬编码依赖,提升系统灵活性和扩展性。配置文件解耦、反射创建对象,新增产品族无需修改客户端代码。示例中,`CoffeeFactory`类加载配置文件并使用反射生成咖啡对象,客户端调用时只需指定名称即可获取对应产品实例。
86 40
|
18天前
|
设计模式 Java 开发者
「全网最细 + 实战源码案例」设计模式——适配器模式
适配器模式(Adapter Pattern)是一种结构型设计模式,通过引入适配器类将一个类的接口转换为客户端期望的另一个接口,使原本因接口不兼容而无法协作的类能够协同工作。适配器模式分为类适配器和对象适配器两种,前者通过多重继承实现,后者通过组合方式实现,更常用。该模式适用于遗留系统改造、接口转换和第三方库集成等场景,能提高代码复用性和灵活性,但也可能增加代码复杂性和性能开销。
67 28
|
14天前
|
设计模式 存储 安全
「全网最细 + 实战源码案例」设计模式——组合模式
组合模式(Composite Pattern)是一种结构型设计模式,用于将对象组合成树形结构以表示“部分-整体”的层次结构。它允许客户端以一致的方式对待单个对象和对象集合,简化了复杂结构的处理。组合模式包含三个主要组件:抽象组件(Component)、叶子节点(Leaf)和组合节点(Composite)。通过这种模式,客户端可以统一处理简单元素和复杂元素,而无需关心其内部结构。适用于需要实现树状对象结构或希望以相同方式处理简单和复杂元素的场景。优点包括支持树形结构、透明性和遵循开闭原则;缺点是可能引入不必要的复杂性和过度抽象。
72 22
|
18天前
|
设计模式 缓存 Java
「全网最细 + 实战源码案例」设计模式——代理模式
代理模式(Proxy Pattern)是一种结构型设计模式,通过代理对象控制对目标对象的访问并添加额外功能。它分为静态代理和动态代理,后者包括JDK动态代理和CGLIB动态代理。JDK动态代理基于接口反射生成代理类,而CGLIB通过继承目标类生成子类。代理模式适用于延迟初始化、访问控制、远程服务、日志记录和缓存等场景,优点是职责分离、符合开闭原则和提高安全性,缺点是增加系统复杂性。
69 25

热门文章

最新文章