23种设计模式使用场景分析

概述

网上关于设计模式的文章特别多,就不赘述了,我认为在敲代码的时候知道根据当前代码结构选择合适的设计模式是最重要的,知道了要使用哪个设计模式,就可以上网随便百度一下,

简述

创建型模式
这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式,而不是使用 new 运算符直接实例化对象。这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。
  • 工厂模式(Factory Pattern)
  • 抽象工厂模式(Abstract Factory Pattern)
  • 单例模式(Singleton Pattern)
  • 建造者模式(Builder Pattern)
  • 原型模式(Prototype Pattern)
结构型模式
这些模式关注对象之间的组合和关系,旨在解决如何构建灵活且可复用的类和对象结构。
  • 适配器模式(Adapter Pattern)
  • 桥接模式(Bridge Pattern)
  • 过滤器模式(Filter、Criteria Pattern)
  • 组合模式(Composite Pattern)
  • 装饰器模式(Decorator Pattern)
  • 外观模式(Facade Pattern)
  • 享元模式(Flyweight Pattern)
  • 代理模式(Proxy Pattern)
行为型模式
这些模式关注对象之间的通信和交互,旨在解决对象之间的责任分配和算法的封装。
  • 责任链模式(Chain of Responsibility Pattern)
  • 命令模式(Command Pattern)
  • 解释器模式(Interpreter Pattern)
  • 迭代器模式(Iterator Pattern)
  • 中介者模式(Mediator Pattern)
  • 备忘录模式(Memento Pattern)
  • 观察者模式(Observer Pattern)
  • 状态模式(State Pattern)
  • 空对象模式(Null Object Pattern)
  • 策略模式(Strategy Pattern)
  • 模板模式(Template Pattern)
  • 访问者模式(Visitor Pattern)

创建型模式

这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式,而不是使用 new 运算符直接实例化对象。这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。

工厂模式

  • 使用场景

一个调用者要创建一个对象,但是不太确定这个对象的类型,或者说该对象类型有多个想日后方便扩展,比如数据库访问,当用户不知道最后系统采用哪一类数据库,以及数据库可能有变化时,此时可以使用工厂模式,当使用oracle数据库时,需要oracle数据库子类实现接口,当想要增加mysql数据库时,再增加mysql数据库子类实现接口,

  • 核心角色

抽象产品:定义了产品的共同接口或抽象类,它可以是具体产品类的父类或者接口,规定了产品对象的共同方法,

具体产品:实现了抽象产品接口,定义了具体产品的具体行为,

具体工厂:声明了创建产品的具体方法,多个产品可以在工厂中创建多个方法,它可以有多个方便用户创建不同类型的产品,比如创建水果类型的方法和创建不同植物类型的方法,

  • 缺点

每增加一种类型的产品时,都需要增加一个具体产品类和具体子类工厂,使得系统中的类个数成倍增加,另外增加了系统具体类之间的依赖,

抽象工厂模式

实际上是在工厂模式的基础上横向增加了一个产品类型维度,比如水果抽象工厂+水果类型,植物抽象工厂+植物类型,增加了多个产品类型后,在多种产品簇上层抽象了另外一个工厂,

  • 使用场景

系统的产品有多个产品簇,举例:在一个房间里有植物类和水果类,当同时消耗系统里面的植物和水果时,因为产品簇不一样,需要在不同产品簇的工厂方法顶层再抽象一个抽象类,在这个顶层抽象工厂聚合多个同类产品,当一个产品簇中的多个对象被设计成一起工作时,他能保证客户端始终只是用同一个产品簇中的对象,(不同产品簇对象可以有联系)

  • 核心角色

抽象产品:定义了一组产品对象的共同接口或抽象类,描述了产品对象的公共方法,

具体产品:实现了抽象产品接口,定义了具体产品的具体行为,

抽象工厂:声明了一组用于创建产品簇对象的方法,每个方法对应一种产品簇类型,抽象工厂可以是接口或者抽象类,

具体工厂:实现抽象工厂接口,负责创建具体产品对象,

  • 缺点

产品簇扩展困难,需要增加一个系列的产品类,还要增加该产品类的工厂类,以及在顶层抽象工厂类中增加抽象方法,

单例模式

  • 使用场景

这种模式涉及到一个单一的类,该类负责创建自己的对象,同时确保只有单个对象被创建。这个类提供了一种访问其唯一的对象的方式,可以直接访问,不需要实例化该类的对象。当你想要控制一个类只能创建一个实例时,使用单例设计模式,比如windows的进程查看器就是单例的,

  • 核心角色

提供单独实例方法的类:调用该方法N多次,但是只会返回同样的那个实例,

  • 缺点

没有接口,不能继承,与单一职责原则冲突,一个类应该只关心内部逻辑,而不关心外面怎么样来实例化。

建造者模式

  • 使用场景

在软件系统中,有时候面临着"一个复杂对象"的创建工作,其通常由各个部分的子对象用一定的算法构成;由于需求的变化,这个复杂对象的各个部分经常面临着剧烈的变化,但是将它们组合在一起的算法却相对稳定。也就是说一些基本部件不会变,而其组合经常变化的时候,比如去肯德基,汉堡、可乐、薯条、炸鸡翅等是不变的,而其组合是经常变化的,生成出所谓的"套餐"。

  • 核心角色

  • 缺点

如果产品的属性较少,建造者模式可能会导致代码冗余,并且建造者模式增加了系统的类和对象数量。

原型模式

  • 使用场景

  • 核心角色

  • 缺点

结构型模式

适配器模式

  • 使用场景

  • 核心角色

  • 缺点

桥接模式

  • 使用场景

  • 核心角色

  • 缺点

过滤器模式

  • 使用场景

  • 核心角色

  • 缺点

组合模式

  • 使用场景

  • 核心角色

  • 缺点

装饰器模式

  • 使用场景

  • 核心角色

  • 缺点

外观模式

  • 使用场景

  • 核心角色

  • 缺点

享元模式

  • 使用场景

  • 核心角色

  • 缺点

代理模式

  • 使用场景

  • 核心角色

  • 缺点

  • 11
    点赞
  • 8
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值