23种设计模式总结-你想知道的设计模式都在这里
简单工厂模式
简单工厂模式是一种创建型设计模式,通过不同的类型来创建出不同的实例返回给客户端
/**
* 计算器
*/
class Factory
{
function createJiSuanQi(string $symblo) : JiSuan {
switch ($symblo) {
case '+':
return new Add;
case '-':
return new Sub;
case '*':
return new Mul;
case '/':
return new Div;
default:
return '输入错误';
}
return '输入错误';
}
}
策略模式
策略模式用于封装算法,比如商场搞活动,可能频繁发生变化,策略模式只需要替换这些算法就可以,客户端不用考虑这些变化。
加上简单工厂之后只需要根据类型来调用不同的算法就可以了
/**
* 根据策略规则创建策略类
*
*/
class StrategyContext{
private $strategy;
function __construct(string $type)
{
switch($type) {
case 'manjian':
$this->strategy = new StrategyA(100,10);
break;
case 'dazhe':
$this->strategy = new StrategyB(0.5);
break;
}
}
function getMoney($money) {
return $this->strategy->getResult($money);
}
}
客户端调用
$model = new StrategyContext($num1);
$res = $model->getMoney($money);
单一职责原则
每个类只负责一个职责,不产生变化,把一个职责做好
开放封闭原则
高内聚,低耦合,比如上班时间,封闭时间长短,扩展可迟到,采用弹性工作制。 尽可能不修改类而是扩展类,不修改原有代码而是增加新的代码 比如计算机硬件,cpu,主板,内存条,显卡等每一个都是可替换的,一个坏了只需要换新的就可以了,不会影响其他的部分
依赖倒置
抽象不应该依赖细节,细节应该依赖抽象 要针对接口编程,而不是针对实现编程
里氏代换原则
子类型必须能替换掉他们的父类型
装饰模式
动态的给一个对象添加一些额外的职责,就增加功能来说,装饰模式比生成子类更为灵活 装饰模式就是把核心功能包裹起来再添加额外的功能,并且可以随意包裹分层
我觉得中间件和平常写的继承重写方法并调用父类方法也是装饰模式的一种体现
装饰模式使得可以随意搭配,比如穿衣服,不能西装写一个类,西装加皮鞋在写一个类,这样太麻烦,装饰模式就可以自己随意搭配了
代理模式
为其他对象提供一种代理以控制对这个对象的访问方法
工厂方法模式
简单工厂模式是在一个工厂里面判断类型来创建不同的实例,工厂方法是写一个工厂接口,然后一个实例对应一个工厂类,在客户端调用的时候自己去判断调用哪个工厂类,这样增加代码只需要增加实例类和具体工厂类就行啦,只需要扩展代码而不会修改代码
原型模式
用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象
原型模式就是实现clone方法,使用clone方法得到多个实例而不是重新new,这样大大减少了消耗
模板方法模式
模板方法模式就是在父类
中定义整个流程,然后一些地方通过子类继承
来改写获取子类的一些信息,来修改整个流程的一些特定的地方,比如写一个导入类
,然后在子类
中可以定义befor
来在导入前做一些事情
迪米特法则
如果两个类不必直接通信,那么这两个类就不应该发生直接的相互作用,如果其中一个类需要调用另一个类的某一个方法的话,可以通过 第三者转发这个调用
每一个类都应当尽量降低成员的访问权限
外观模式
外观模式我觉得像是一个类来代理多个类的访问,把复杂的聚合成简单的接口对外开放,使得外部只需要知道简单的接口而不用和内部复杂的东西打交道
建造者模式
将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示的意图时,就是建造者模式。建造者模式可以将一个产品的内部表象与产品的生成过程分割开来,从而可以使一个建造过程生成具有不同的内部表象的产品对象。如果我们用了建造者模式,那么用户就只需指定需要建造的类型就可以得到它们,而具体建造的过程和细节就不需要知道了。
观察者模式
观察者模式又叫发布订阅模式
。
观察者模式定义了一种一对多的依赖关系,让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时,会通知所有观察者对象,使他们能够自动更新自己
当什么时候使用观察者模式呢
当一个对象的改变需要改变其他多个对象的时候,而且她不知道要改变多少个对象
事件委托
把观察者要做的事情委托给通知者,也就是观察者的方法
放到通知者里面,然后通知者通知的时候调用这些方法来完成事件委托
委托的前提
委托的前提是委托的方法必须拥有相同的参数列表和返回值类型
抽象工厂模式
提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类
状态模式
当一个对象的内在状态改变时允许改变其行为,这个对象看起来像是改变了其类
状态模式主要解决的是当控制一个对象状态转换的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同状态的一系列类当中,可以把复杂的判断逻辑简化。
什么时候考虑状态模式
当一个对象的行为取决于它的状态,并且它必须在运行时刻根据状态改变它的行为时,就可以考虑使用状态模式了
适配器模式
将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作
备忘录模式
在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态。这样以后就可以将该对象恢复到原先保存的状态
组合模式
将对象组合成树形结构以表示‘部分-整体’的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性
迭代器模式
提供一种方法顺序访问一个聚合对象中各个元素,而又不暴露该对象的内部表示
单例模式
桥接模式
将抽象部分与它的实现部分分离,使它们都可以独立的变化
什么叫抽象与它的实现分离,这并不是说,让抽象类与其派生类分离,因为这并没有任何意义。实现指的是抽象类和它的派生类用来实现自己的对象。
手机品牌->{手机品牌m -> {手机品牌m游戏功能,手机m电话功能}, 手机品牌n -> {n游戏, n电话}}
手机功能->{游戏->{m游戏,n游戏}, 电话->{m电话 ,n电话}}
由于实现的方式有多种,桥接模式的核心意图就是把这些实现独立出来,让它们各自的变化。这就使得每种实现的变化不会影响其他实现,从而达到应对变化的目的
手机品牌->{m ,n}
手机功能->{游戏,电话}
把游戏放到品牌m里面就是m游戏,把电话放到品牌里面就是m电话,增加个音乐功能就多个音乐功能类,然后把音乐传给m,就可以m音乐
命令模式
将一个请求封装为一个对象,从而使你可用不同的请求对客户进行参数化;对请求排队或记录请求日志,以及支持可撤销的操作。
服务员给厨师下命令说做哪些菜,烤羊肉串,烤鸡翅,宫保鸡丁,服务员存下这些命令,然后统一下达给厨师,需要有烤羊肉类,鸡翅类这些命令类
,这些命令类只需要知道谁是执行者就可以了,厨师是执行者,然后把这些命令类传给服务员,服务员使用命令类给厨师下达命令
职责链模式
使多个对象都有机会处理请求,从而避免请求的发送者和接受者之间的耦合关系。将这个对象连城一条链,并沿着这条链传递该请求,直到有一个对象处理它为止。
中介者模式
尽管将一个系统分割成虚许多对象通常可以增加其可复用性,但是对象间相互连接的激增又会降低其可复用性。
大量的连接使得一个对象不可能在没有其他对象的支持下工作,系统表现为一个不可分割的整体,所以,对系统的行为进行任何较大的改动就十分困难了。
用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式的相互引用,从而使其耦合松散,而且可以独立地改变它们之间的交互
中介者模式一般应用于一组对象以定义良好但是复杂的方式进行通信的场合,比如刚才得到的窗体form对象或web页面aspx,以及想定制一个分布在多个类中的行为,而又不想生成太多的子类的场合
享元模式
运用共享技术有效的支持大量细粒度的对象
享元模式可以避免大量非常相似类的开销。在程序设计中,有时需要生成大量细粒度的类实例来表示数据。如果能发现这些实例除了几个参数外基本上都是相同的,有时就能够受大幅度的减少需要实例化的类的数量。如果能把那些参数移到类实例的外面,在方法调用时将他们传递进来,就可以通过共享大幅度的减少单个实例的数目。
如果一个应用使用了大量的对象,而大量的这些对象造成了很大的存储开销时就应该考虑使用;还有就是对象的大多数状态可以外部状态,如果删除对象的外部状态,那么可以用相对较少的共享对象取代很多组对象,此时可以考虑使用享元模式。
解释器模式
给定一个语言,定义它的文法的一种表示,并定义一个解释器,这个解释器使用该表示来解释语言中的句子。
如果一种特定类型的问题发生的频率足够高,那么可能就值得将该问题的各个实例表述为一个简单语言中的句子。这样就可以构建一个解释器,该解释器通过解释这些句子来解决该问题。
访问者模式
表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
访问者模式的目的
访问者模式的目的是要把处理从数据结构分离出来。很多系统可以按照算法和数据结构分开,如果这样的系统有比较稳定的数据结构,又有易于变化的算法的话,使用访问者模式就是比较合适的,因为访问者模式使得算法操作的增加变得容易。
访问者的缺点时增加新的数据结构变得困难
转载自:https://juejin.cn/post/7146013998482194462