![](https://img-blog.csdnimg.cn/20201014180756927.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
设计模式
haliary_wow
这个作者很懒,什么都没留下…
展开
-
迪米特原则
简介 迪米特原则: 如果两个类不必彼此通信,那么这两个类就不应当发生直接的相互作用, 如果其中一个类需要调用另一个类的某个方法的话,可以通过第三者转发这个调用。前提 在类的结构设计上每一个类都应当尽量降低成员的访问。实现 一个模块设计的好坏的一个重要标志就是该模块在多大程度上讲自己的内部数据与实现的有关细节隐藏起来。 一个软件实体应当尽可能少的与其他实体发生相互作用。 每一个软件单位对转载 2017-11-15 13:46:41 · 316 阅读 · 0 评论 -
外观模式
简介 外观模式: 为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层接口,这个接口使得这个子系统更加容易使用。常用的场景 1.在设计初期阶段,应该有意识的将不同的两个层分离。 2.在开发阶段,子系统往往因为不断的重构而变得越来越复杂,我们通过添加外观来提供简单的接口,减少他们的依赖。 3.在维护大型的系统时,系统本身很难进行维护和扩充,新开发的系统添加外观来提供简单的接口实现交互转载 2017-11-15 14:18:01 · 113 阅读 · 0 评论 -
备忘录模式
简介 备忘录模式: 在不破坏封装性的前提下,捕捉一个对象的内部状态,并在该对象外保存这个状态,这样以后就可将该对象恢复到原先保存的状态。转载 2017-11-20 15:27:34 · 117 阅读 · 0 评论 -
组合模式
简介组合模式:将对象组合成树的结构以表示“部分-整体”的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。构成1.Component是组合中的对象声明接口,在适当的情况下,实现所有类共有接口的默认行为。声明一个接口用于访问和管理Component子部件。2.Leaf 在组合中表示叶子结点对象,叶子结点没有子结点。3.Composite 定义有枝节点行为,用转载 2017-11-30 10:20:11 · 114 阅读 · 0 评论 -
迭代器模式
简介迭代器模式:提供一种方法顺序访问一个聚合对象的各个元素,而又不暴露该对象的内部表示。构成1.迭代器抽象类。2.聚集抽象类。3.具体迭代器类。4.具体聚集类。常用的场景需要对聚集有多种方式的遍历时使用迭代器模式。类图:自行百度。。。测试代码 #include #include #include using namespace std;转载 2017-11-30 12:34:42 · 101 阅读 · 0 评论 -
建设者模式
简介 建造者模式: 将一个复杂对象的构建和他的表示分离,使得相同的构造过程可以创建不同的表示。 重点:相同的构造过程产生不同的表示。构成 Product产品类,通过模板方法模式实现,有基本方法和模板方法 Builder抽象建造者,规范产品的组件,一般由子类实现 ConcreteBuilder具体建造者,实现抽象类定义的所有方法,并返回一个创建好的对象 Director导演类,负责安排已转载 2017-11-16 17:18:29 · 208 阅读 · 0 评论 -
单例模式
简介单例模式:保证一个类有且只有一个实例,并提供一个访问它的全局访问点。常用的场景单例模式常常与工厂模式结合使用,因为工厂只需要创建产品实例就可以了,在多线程的环境下也不会造成任何的冲突,因此只需要一个工厂实例就可以了。优点:1.减少了时间和空间的开销(new实例的开销)。2.提高了封装性,使得外部不易改动实例。缺点:1.懒汉式是以时间换空间的方式。2.饿汉原创 2017-12-01 10:21:06 · 109 阅读 · 0 评论 -
桥接模式
简介桥接模式:将抽象部分与他的实现部分分离,是他们可以独立变化。类图组成对象1、Abstraction::Operation():定义要实现的操作接口2、AbstractionImplement::Operation():实现抽象类Abstaction所定义操作的接口,由其具体派生类ConcreteImplemenA、ConcreteImplemenA或者其他派转载 2017-12-01 11:08:26 · 119 阅读 · 0 评论 -
命令模式
简介命令模式:将一个请求封装成一个对象,从而使你可用不同的请求对客户进行参数化:对请求排队或记录请求日志,以及支持可撤销操作。类图 组成对象Receiver接受者角色,就是干活的码农,命令传递打这里就应该被执行。Command命令角色,对命令额封装,所有命令声明在此Invoker调用者角色,接受到命令并且执行命令常用的场景只要认为是命令的地方,eg GUI转载 2017-12-04 14:20:54 · 121 阅读 · 0 评论 -
职责链模式
简介职责链模式:使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系。将这个对象连成一条链,并且沿着这条链传递请求,知道有一个对象处理它为止。常用的场景1.有多个对象可以处理同一个请求,具体哪个对象处理该请求由运行时刻自动确定。 2.在不明确指定接收者的情况下,向多个对象中的一个提交一个请求。 3.可动态指定一组对象处理请求。优点:1. 将请求和处转载 2017-12-04 14:38:03 · 105 阅读 · 0 评论 -
中介者模式
简介中介者模式:用一个中介对象封装一系列的对象交互。中介者使各对象不需要显式的相互引用,从而使其耦合松散,而且了以独立的改变他们之间的交互。 组成对象Mediator抽象中介者角色,定义统一接口,用于各个同事角色之间的通信ConcreteMediator具体中介者角色,通过协调各个同事角色实现协作行为,依赖于各个同事Colleague同事角色,每个同事角色都应该知道中介转载 2017-12-06 10:16:39 · 121 阅读 · 0 评论 -
享元模式
简介享元模式:运用共享技术有效的支持大量细粒度的对象。 组成对象Flyweight抽象享元角色,一个产品的抽象,定义内部状态和外部状态的接口或者实现。ConcreteFlyweight具体享元角色,实现抽象角色定义的业务。注:内部状态处理和环境无关。unsharedConcreteFlyweight不可共享的享元角色,不存在外部状态或者安全要求,不能够使用共性技术的对象转载 2017-12-06 10:43:56 · 155 阅读 · 0 评论 -
适配器模式
适配器模式: 将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。转载 2017-11-20 15:08:09 · 107 阅读 · 0 评论 -
模板方法模式
简介 模板方法模式: 定义一个操作中的算法的骨架,而将一些步骤延迟到子类当中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的特定步骤。常用的场景 多个子类有共有的方法,并且逻辑相同/逻辑相同,细节有差异。 对重要,复杂的算法,可以讲核心算法设计为模板方法,周边细节由子类实现。 重构时,经常使用的方案,将相同的代码抽象到父类,通过构造函数约束行为。优点 封装不变部分/逻辑框架,转载 2017-11-15 11:34:36 · 146 阅读 · 0 评论 -
观察者模式
简介 观察者模式: 定义了一个一对多的依赖关系,让多个观察者对象同时监听某一个主题对象。这个主题对象发生变化时,会通知所有的观察者对象,使它们可以自动更新自己。构成 Subject(目标) 目标知道它的观察者。可以有任意多个观察者观察同一个目标; 提供注册和删除观察者对象的接口。 Observer(观察者) 为那些在目标发生改变时需获得通知的对象定义一个更新接口。 ConcreteS转载 2017-11-16 18:25:45 · 148 阅读 · 0 评论 -
简单工厂模式
简介简单工厂模式是属于创建型模式,又叫做静态工厂方法(Static FactoryMethod)模式,但不属于23种GOF设计模式之一。简单工厂模式是由一个工厂对象决定创建出哪一种产品类的实例。简单工厂模式是工厂模式家族中最简单实用的模式,可以理解为是不同工厂模式的一个特殊实现。常用的场景例如部署多种数据库的情况,可能在不同的地方要使用不同的数据库,此时只需要在配置文件中设定数据库的类转载 2017-10-09 11:30:57 · 112 阅读 · 0 评论 -
策略模式
简介策略模式是定义一系列算法的方法,从概念上看所有这些算法都是相同的工作,只是实现不同,它可以通过相同的方式调用所有的算法,减少算法类与使用算法类之间的耦合常用的场景1.客户端提供一个方法接口,需要多个算法类切换使用。算法类的功能相同但是表现形式不一致的时候2.算法类存在扩展需求或者需要根据不同情况切换算法类的时候3.对外隐藏算法细节优点1.策略模式提供了管理相关的转载 2017-10-09 14:27:32 · 188 阅读 · 0 评论 -
单一职责原则
简介单一职责原则:就一个类而言,应该仅有一个引起它变化的原因原理1.类的职责过多会导致耦合度的提升,在维护代码时产生意想不到的问题。优点1.类的复杂性降低,实现什么职责都有清晰明确的定义。2.可读性提高,复杂性降低。3.可维护性提高4.变更引起的风险降低,变更是必不可少的,如果接口的单一职责做的好,一个接口修改只对相应的实现类有影响,对其他的接口无影响,这对系统的扩转载 2017-10-09 14:41:59 · 144 阅读 · 0 评论 -
开放-封闭原则
简介开放-封闭原则:软件实体(类,模块,函数等等)应该可以扩展但是不可修改。对于扩展是开放的,对于更改是封闭的。面对需求变化时,我们是增加代码,而不是改变原有的代码,当需求变化发生时,我们就创建抽象来隔离以后将要发生同类的变化目的1.在软件的生命周期内,因为变化、升级和维护等原因需要对软件原有代码进行修改时,可能会给旧代码中引入错误,也可能会使我们不得不对整个功能进行重构,并且转载 2017-10-09 15:00:38 · 178 阅读 · 0 评论 -
依赖倒转原则
简介依赖倒转原则:1.高层模块不应该以来底层模块,两个都应该依赖抽象2.抽象不应该依赖细节,细节应该依赖抽象针对接口编程,不要对实现编程 里氏代换原理:子类型必须能够替换调幅类型目的一个应用中的重要策略决定及业务模型正是在这些高层的模块中。也正是这些模型包含着应用的特性。但是,当这些模块依赖于低层模块时,低层模块的修改将会直接影响到它们,迫使它们也去改变。应该高层的转载 2017-10-09 16:22:39 · 198 阅读 · 0 评论 -
装饰模式
简介装饰模式:动态的给一个对象添加一些额外的职责,就增加功能而言,装饰模式比生成子类更加灵活。常用的场景如果需要添加新功能,但又不想修改定义好的接口或者抽象类,那么这时候就比较适合装饰模式,例如很多图形系统中的组件,就可以使用装饰模式,来让新的组件在继承现在功能的基础上添加新的功能。装饰模式一般是针对接口或者抽象类的变化,如果是具体实现类的变化,则要考虑适用哪种模式。优点转载 2017-11-01 14:16:45 · 121 阅读 · 0 评论 -
代理模式
简介代理模式:为其他对象提供一种代理以控制对这个对象的访问。在某些情况下,一个对象不适合或者不能直接引用另一个对象,而代理对象可以在客户端和目标对象之间起到中介的作用。常用的场景1.虚拟(Virtual)代理:根据需要创建一个资源消耗较大的对象,使得此对象只在需要时才会被真正创建。使用虚拟代理模式的好处就是代理对象可以在必要的时候才将被代理的对象加载;代理可以对加载的过程加以必原创 2017-11-01 15:22:21 · 154 阅读 · 0 评论 -
原型模式
#include #include using namespace std;//原型类class FBookProtoType{public: FBookProtoType(){}; ~FBookProtoType(){}; int name; int price; int num; //深拷贝 FBookProtoType* deepClone() { FB转载 2017-11-02 16:29:40 · 179 阅读 · 0 评论 -
抽象工厂模式
简介 抽象工厂模式: 提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。构成 产品基类:这里包含产品基类A和产品基类B,这两个产品都从共同的基类继承而来,但是这个继承关系却是在这个模式之外的部分,而本身这个模式关心的是这两个产品基类的差异部分。 具体产品类:这里的具体产品类是产品A1,A2,B1、B2等, 工厂抽象接口:定义了创建产品的接口,这里返回参数是返回的产品A,产转载 2017-11-17 15:17:53 · 120 阅读 · 0 评论 -
状态模式
简介 状态模式: 当一个对象的内在状态改变时允许改变其行为,这个对象看起来像是改变了其类。 状态模式主要解决的是当控制一个对象状态转换条件表达式过于复杂时的情况。吧状态的判断逻辑转移到表示不同状态的一系列类当中,可以把复杂的判断逻辑简化。构成 上下文环境(Context):它定义了客户程序需要的接口并维护一个具体状态角色的实例,将与状态相关的操作委托给当前的Concrete State对象来转载 2017-11-17 16:44:30 · 99 阅读 · 0 评论 -
工厂模式
简介 工厂模式: 工厂模式基本与简单工厂模式差不多,上面也说了,每次添加一个产品子类都必须在工厂类中添加一个判断分支,这样违背了开放-封闭原则,因此,工厂模式就是为了解决这个问题而产生的。 定义一个用于创建对象的接口,让子类决定实例化哪一个类,工厂方法使每一个类的实例化延迟到子类.优点 1不用修改已有代码,开放封闭原则: 2对扩展开放,对更改封闭与简单工厂模式区别 简单工厂模式:一个工厂转载 2017-11-17 16:48:07 · 144 阅读 · 0 评论 -
解释器模式
简介解释器模式:给定一个语言,定义它的文法的一种表示,并定义一个解释器,这个解释器使用该表示来解释语言中的句子。 组成对象抽象解释器:声明一个所有具体表达式都要实现的抽象接口(或者抽象类),接口中主要是一个interpret()方法,称为解释操作。具体解释任务由它的各个实现类来完成,具体的解释器分别由终结符解释器TerminalExpression和非终结符解释器Nonterm转载 2017-12-07 16:16:53 · 124 阅读 · 0 评论