![](https://img-blog.csdnimg.cn/20201014180756922.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
设计模式
子歆
这个作者很懒,什么都没留下…
展开
-
设计模式之命令模式
命令模式:将一个请求封装为一个对象,从而使你可用不同的请求客户进行参数化;对请求排队或记录请求日志,以及支持可撤销的操作。 命令模式就是一个请求接口,将一个操作的对象和对象的执行分割开。互不干涉。较为容易的实现命令的队列,记入日志和请求的撤销和重做等一些操作。 一个简单的命令模式的说明代码: #include<iostream> using namespace std; c...原创 2019-01-04 11:11:04 · 62 阅读 · 0 评论 -
设计模式之装饰模式
装饰模式:动态地给一个对象添加一些额外的职责,就增加功能来说,装饰比生成子类更灵活。 优点: 不用修改原来的接口,即可添加新的功能。比静态继承灵活,静态继承增加了许多新类,增加了系统的复杂度。 方便转换原来接口的实现。 缺点: 复杂性的增加,类的数量会有所增加。 适用于: 在不影响其它对象的情况下,动态、透明的给单个对象添加职责。 ...原创 2019-01-16 09:19:09 · 91 阅读 · 0 评论 -
设计模式之模板模式
模板模式就是提供了一个很好的代码复用平台,当不变的和可变的行为在方法的子类实现中混合在一起的时候,不变的行为就会在子类中重复出现。通过模板模式把这些行为搬移到单一的地方,这样帮助子类摆脱重复的不变行为的纠缠。 特点:通过把不变行为搬移到超类,去除子类中的重复代码来体现它的优势。 实现是把算法或框架放在抽象父类中定义,并定义一个接口,在子类中实现。 优点:封装不变,可扩展细节和可变的行为;父类...原创 2019-01-22 08:27:10 · 64 阅读 · 0 评论 -
设计模式之代理模式
代理模式:为其他对象提供一种代理以控制对这个对象的访问。 解决了直接访问该对象所带来的问题。 增加了中间层,实现了与被代理类的组合。 优点:职责清晰;扩展性强;智能化。 缺点:增加了类,可能造成处理的速度变慢;增加了额外的类,实现变得复杂。 适用于:远程代理;虚拟代理;Copy-on-Write 代理;保护(Protect or Access)代理;Cache代理;防火墙(Firewal...原创 2019-01-16 20:16:38 · 80 阅读 · 0 评论 -
设计模式之外观模式
外观模式:为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。 三个阶段的不同使用: 设计初期阶段,应该要有意识的将不同的两层分离; 开发阶段,子系统往往因为不断的重构演化而变得越来越复杂;增加外观可以提供一个简单的接口,减少它们之间的依赖; 在维护一个遗留的大型系统时,可能这个系统已经非常难以维护和扩展。 适用于为一个复杂的子系统提供一...原创 2019-01-23 08:34:09 · 95 阅读 · 0 评论 -
设计模式之适配器模式
适配器模式:将一个类的接口转换成客户希望的另外一个接口。使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。 目的是使控制范围之外的一个原有对象与某个接口匹配。 适用于希望复用一些现存的类,但是接口又与复用环境要求不一致的情况。 适配器模式有两种类型:类适配器模式和对象适配器模式。 类适配器代码: //类适配器 #include <iostream> #includ...原创 2019-02-22 08:22:50 · 64 阅读 · 0 评论 -
设计模式之原则
这是最后一篇设计模式的文章了,如果以后在学习中学到其他的设计模式将再继续补充,今天说一下设计模式中的几个原则,可以让我们更好的理解设计模式。 单一职责原则:就一个类而言,应该仅有一个引起它变化的原因。 解释:如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不...原创 2019-02-28 08:33:08 · 67 阅读 · 0 评论 -
设计模式之备忘录模式
定义:在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态。这样以后可将该状态恢复到原先保存的状态。 适用于功能比较复杂,但需要维护或记录属性历史的类,或者需要保存的属性只是属性中的一小部分时,可以根据保存的属性信息还原到前一状态。 代码: //备忘录模式 #include <iostream> #include <string> usin...原创 2019-02-25 08:50:50 · 69 阅读 · 0 评论 -
设计模式之抽象工厂模式
抽象工厂模式:提供一个创建一系列相关或相互依赖对象的接口,而无需指定他们具体的类。 优点: 在一个应用中只需要在初始化的时候出现一次,这就使得改变一个应用的具体工厂变得非常容易,只需改变具体工厂即可使用不同的产品配置。 它让具体的创建实例过程与客户端分离,客户端是通过他们的抽象接口操作实例,产品的具体类名也被具体工厂的实现分离,不会出现在代码中。 缺点: 增加新的功能时,需要添...原创 2019-02-20 09:45:08 · 64 阅读 · 0 评论 -
设计模式之组合模式
定义:将对象组合成树形结构以表示‘部分-整体’的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。 优点: 基本对象可以被组合成更复杂的组合对象,而这个组合对象又可以被组合,这样不断地递归下去,客户代码中,任何用到基本对象的地方都可以使用组合对象。 组合模式让客户可以一致地使用组合结构和单个对象。 缺点:必须有一致地行为。 适用于组织结构,产品结构的整体与部分的结构。 代码...原创 2019-02-26 08:46:01 · 83 阅读 · 0 评论 -
设计模式之状态模式
状态模式:当一个对象的内在状态改变时允许改变其行为,这个对象看起来像是改变了其类。 状态模式主要解决的是当控制一个对象状态转换的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同状态的一系列类当中,可以把复杂的判断逻辑简化。 状态模式通过把各种状态逻辑分布到state的子类之间,减少了相互间的依赖。 优点:将与特定状态相关的行为局部化,并且将不同状态的行为分割开来。 目的:为了消除...原创 2019-02-21 08:43:15 · 58 阅读 · 0 评论 -
设计模式之解释器模式
解释器模式:给定一个语言,定义它的文法的一种表示,并定义一个解释器,这个解释器使用该表示来解释语言中的句子。 优点:容易改变和扩展文法,因为该模式使用类来表示文法规则,可以使用继承来改变或扩展该文法,比较容易实现文法,因为定义抽象语法树中各个节点的类实现大体类似,易于直接编写。 不足:解释器模式为文法中的每一条规则至少定义了一个类,因此包含许多规则的文法可能难以管理和维护。文法容易时,可使用。...原创 2019-01-10 11:00:35 · 110 阅读 · 0 评论 -
设计模式之原型模式
原型模式:用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象。 原型模式其实就是从一个对象再创建另外一个可定制的对象,而且不需要知道任何创建的细节。 优点: 利用原型模式比new一个对象更能提高效率。 简化对象创建,不需要了解创建过程。 缺点: 深拷贝时代码实现复杂。 适用于创建新对象成本大时,利用已有的对象来复制。 ...原创 2019-01-21 09:09:40 · 74 阅读 · 0 评论 -
设计模式之策略模式
策略模式:定义了算法家族,分别封装起来,让它们之间可以相互转换,此模式让算法的变化,不会影响到使用算法的客户。 从概念上来看,所有的这些算法完成的都是相同的工作,只是实现不同,它可以以相同的方式调用所有的算法。 优点:算法可以自由切换,扩展性好。 缺点:策略增多时,上层必须知道具体的策略。 适用于多个类只在算法上不同的地方。 用策略模式实现商场促销: #include <ios...原创 2019-01-15 09:23:07 · 126 阅读 · 0 评论 -
设计模式之访问者模式
访问者模式:表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。 访问者模式适用于数据结构相对稳定的系统。 访问者模式把数据结构和作用于结构上的操作之间的耦合解脱开,使得操作集合可以相对自由地演化。 访问者模式的目的是把处理数据结构分离出来。 有比较稳定的数据结构,又易于变化的算法的话,使用访问者模式就是比较适合的,因为访问者模式使得算...原创 2019-01-11 11:07:54 · 246 阅读 · 0 评论 -
设计模式之单例模式
虽然不是在设计模式中看得第一个模式,但是这是第一个写博客的模式,之前的学习的工厂模式后续再写,这是一个不简单的设计模式,再我看过的设计模式中单例模式虽然没有把面向对象的三大特性全部表现出来。但是,我感觉依然还是不容易理解的。接下来言归正传,说一下单例模式。 单例模式必须保证一个类只能生成一个实例。并提供一个全局的访问点,该实例是被所有的程序所共享的。也就是说在使用这个类是只能有一个对象产生,就像...原创 2019-01-02 15:01:01 · 73 阅读 · 0 评论 -
设计模式之职责链模式
职责链模式:使多个对象都有机会处理请求,从而避免请求的发送者和接受者之间的耦合关系,将这个对象连成一条链,并沿着这条链传递该请求,知道有一个对象处理它为止。 优点 : 责任链对象只和自己的后继有耦合关系,与其他的对象没有关系。 在职责中,责任链对程序更加灵活。 可以动态的增加或删除处理者,也可以改变先后顺序。 用户不必考虑处理者的信息。 基本的模型代码: #include <...原创 2019-01-07 10:59:49 · 124 阅读 · 0 评论 -
设计模式之桥接模式
桥接模式是将抽象部分与它的实现部分分离,使它们都可以独立地变化。 例如现在的手机硬件与软件,电脑硬件和软件,都是通过不同的厂商来开发的。它们之间都不是谁依赖谁的关系,都是往中间抽象层依靠。 手机与软件实现: //合成/聚合复用原则:尽量使用合成/聚合,尽量不要使用类继承 #include <iostream> using namespace std; class Hands...原创 2019-01-03 10:30:55 · 91 阅读 · 0 评论 -
设计模式之工厂模式
工厂模式:定义了一个用于创建对象的接口,让子类决定实例化哪一个类,工厂方法使一个类的实例化延迟到其子类。 工厂方法模式:是简单工厂模式的衍生,解决了许多简单工厂模式的问题。首先完全实现‘开放-封闭 原则’,实现了可扩展。其次更复杂的层次结构,可以应用于产品结果复杂的场合。 利用工厂模式实现四则远算: #include <iostream> #include <string...原创 2019-01-18 09:45:21 · 70 阅读 · 0 评论 -
设计模式之中介者模式
中介者模式:用一个中介对象来封装一些列对象的交互。中介者使个对象不需要显式地向后引用,从而使其耦合松散,而且可以独立地改变他们之间的交互。 中介者降低了各个具体类之间的耦合,使其独立开来,但是随着具体类的增加,会变得很复杂。 适用于一组对象以定义良好但复杂的方式进行通信的场合,以及想定制一个分布在多个类中的行为,而又不想生成太多的子类的场合。 注意:中介者在传递消息时需要判断当前参数所指的对...原创 2019-01-08 09:52:35 · 104 阅读 · 0 评论 -
设计模式之建造者模式
建造者模式:将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。 优点: 封装性:封装了具体步骤,减少冗余。 易扩展性:建造者独立,扩展性强。 缺点: 建造的算法不能发生太大的变化,否则影响灵活性。 适用于多个方法不同顺序,多个部件组装但结果不同等场景。 代码实现: //builder.h #ifnd...原创 2019-01-24 09:10:04 · 92 阅读 · 0 评论 -
设计模式之简单工厂
简单工厂是一种实例化对象的方式,通过工厂对象制作你想要的对象。 简单工厂体现了面向对象封装、继承、多态的三大基本特点,通过父类指针指向子类对象,动态的重写子类的函数。 先来看一下一个范例: #include <iostream> #include <cstring> using namespace std; class Fruit { public: vi...原创 2019-01-14 10:11:29 · 90 阅读 · 0 评论 -
设计模式之享元模式
享元模式:运用共享技术有效地支持大量细粒度的对象。 享元模式分为内部状态和外部状态。 在享元对象内部并且不会随环境变化而变化的共享部分,成为享元对象的内部部分,而随环境变化而变化的、不可共享的状态称为外部状态。 享元模式避免了大量的非常相似类的开销。可以通过共享减少单个实例的数目开销。 如果一个应用程序使用大量的对象,而大量的对象造成了很大的存储开销时可以考虑使用享元模式;同时,对象的大多...原创 2019-01-09 10:11:06 · 105 阅读 · 1 评论 -
设计模式之观察者模式
观察者模式定义了一种一对多的依赖关系,让多个观察者对象同时监听某一个主题对象。当这个主题对象再状态发生变化时,会通知所有观察者对象,使它们能够自动更新自己。 适用于当一个对象的改变需要同时改变其他对象时,而且不知道具体有多少对象有待改变时。 优点:目标者与观察者之间松耦合;支持广播通信 缺点:观察者错误更新会影响整个系统。 代码实现: #include <iostream>...原创 2019-01-25 08:56:46 · 74 阅读 · 0 评论 -
设计模式之迭代器模式
定义:提供一种方法顺序访问一个聚合对象中各个元素,而又不暴露该对象的内部表示。 适用于: 一个聚集对象而无需暴露它内部表示 对聚集有多种方式遍历 为遍历不同的聚集结构提供接口。 实质:就是分离了集合对象的遍历行为,抽象出一个迭代器类来负责,这样既可以做到不暴露集合的内部结构,又可让外部代码透明地访问集合的数据。 代码实现: #include <iostream> #inc...原创 2019-02-27 09:08:27 · 54 阅读 · 0 评论