设计模式
文章平均质量分 79
几番离愁
这个作者很懒,什么都没留下…
展开
-
设计模式 - 访问器(Visitor)
动机 在软件构建过程中,由于需求的改变,某些类层次结构中常常需要增加新的行为(方法),如果直接在基类中做这样的更改,将会给子类带来很繁重的变更负担,甚至破坏原有设计。 如何在不更改类层次结构的前提下,在运行时根据需 要透明地为类层次结构上的各个类动态添加新的操作,从而避免上述问题?模式定义 表示一个作用于某对象结构中的各元素的操作。使得可以在不改变(稳定)各元素的类的前提下定义(扩展)作用于这些元素的新操作(变化)。结构类图案例分析未使用设计模式class Element{pub原创 2020-05-27 22:52:52 · 188 阅读 · 0 评论 -
设计模式 - 命令模式(Command)
动机 模式定义 结构类图案例分析未使用设计模式使用要点总结以上内容来源于李建忠老师的c++设计模式原创 2020-05-27 20:14:18 · 187 阅读 · 0 评论 -
设计模式 - 职责链(Chain of Resposibility)
动机 在软件构建过程中,一个请求可能被多个对象处理,但是每个请求在运行时只能有一个接受者,如果显式指定,将必不可少地带来请求发送者与接受者的紧耦合。 如何使请求的发送者不需要指定具体的接受者?让请求的接受者自己在运行时决定来处理请求,从而使两者解耦。模式定义 使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链,并沿着这条链传递请求,直到有一个对象处理它为止。结构类图案例分析enum class RequestType{ REQ_HAN原创 2020-05-27 17:01:41 · 175 阅读 · 0 评论 -
设计模式 - 迭代器(Iterator)
动机 在软件构建过程中,集合对象内部结构常常变化各异。但对于这些集合对象,我们希望在不暴露其内部结构的同时,可以让外部客户代码透明地访问其中包含的元素;同时这种“透明遍历”也为“同一种算法在多种集合对象上进行操作”提供了可能。 使用面向对象技术将这种遍历机制抽象为"迭代器对象” 为“应对变化中的集合对象”提供了一种优雅的方式。模式定义 提供一种方法顺序访问一个聚合对象中的各个元素,而又不暴露(稳定)该对象的内部表示。结构类图案例分析template<typename T>原创 2020-05-27 16:29:27 · 161 阅读 · 0 评论 -
设计模式 - 组合模式(Composite)
动机 在软件在某些情况下,客户代码过多地依赖于对象容器复杂的内部实现结构,对象容器内部实现结构(而非抽象接口)的变化将引起客户代码的频繁变化,带来了代码的维护性、扩展性等弊端。 如何将“客户代码与复杂的对象容器结构”解耦?让对象容器自己来实现自身的复杂结构,从而使得客户代码就像处理简单对象一样来处理复杂的对象容器?模式定义 将对象组合成树形结构以表示" 部分 一 整体”的层次结构。Composite使得用户对单个对象和组合对象的使用具有一致性(稳定)。结构类图案例分析class Com原创 2020-05-27 15:47:28 · 229 阅读 · 0 评论 -
设计模式 - 备忘录(Memento)
动机 在软件构建过程中,某些对象的状态在转换过程中,可能由于某种需要,要求程序能够回溯到对象之前处于某个点时的状态。如果使用一些公有接口来让其他对象得到对象的状态,便会暴露对象的细节实现。 如何实现对象状态的良好保存与恢复?但同时又不会因此而破坏对象本身的封装性。模式定义 在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态。这样以后就可以将该对象恢复到原先保存的状态。结构类图案例分析class Memento{ string state; //原创 2020-05-27 14:37:25 · 185 阅读 · 0 评论 -
设计模式 - 状态模式(State)
动机 在软件构建过程中,某些对象的状态如果改变,其行为也会随之而发生变化,比如文档处于只读状态,其支持的行为和读写状态支持的行为就可能完全不同。 如何在运行时根据对象的状态来透明地更改对象的行为?而不会为对象操作和状态转化之间引入紧耦合?模式定义 允许一个对象在其内部状态改变时改变它的行为。从而使对象看起来似乎修改了其行为。结构类图案例分析 某个网络任务类设计,有三种网络模式,每个接口对应某种模式所做的任务都不一样,且做完之后需要切换状态未使用设计模式enum NetworkSt原创 2020-05-27 14:16:40 · 177 阅读 · 0 评论 -
设计模式 - 中介者(Mediator)
动机 在软件构建过程中,经常会出现多个对象互相关联交互的情况,对象之间常常会维持一种复杂的引用关系 ,如果遇到一些需求的更改,这种直接的引用关系将面临不断的变化。 在这种情况下,我们可使用一个“中介对象”来管理对象间的关联关系,避免相互交互的对象之间的紧耦合引用关系,从而更好地抵御变化。模式定义 用一个中介对象来封装(封装变化)一系列的对象交互。中介者使各对象不需要显式的相互引|用(编译时依赖→运行时依赖) ,从而使其耦合松散(管理变化),而且可以独立地.改变它们之间的交互。结构类图案例原创 2020-05-26 22:58:56 · 199 阅读 · 0 评论 -
设计模式 - 适配器(Adapter)
动机 在软件系统中,由于应用环境的变化,常常需要将“一些现存的对象”,放在新的环境中使用,但是新环境要求的接口是这些现存对象所不满足的。 如何应对这种“迁移的变化”?如何既能利用现有对象的良好实现,同时又能满足新的应用环境所要求的接口?模式定义 将一个类的接口转换成客户希望的另一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。结构类图案例分析//目标接口(新接口)class ITarget{public: virtual void pro原创 2020-05-26 22:16:55 · 144 阅读 · 0 评论 -
设计模式 - 代理模式(Proxy)
动机 在面向对象系统中,有些对象由于某种原因(比如对象创建的开销很大,或者某些操作需要安全控制,或者需要进程外的访问等 ),直接访问会给使用者、或者系统结构带来很多麻烦。 如何在不失去透明操作对象的同时来管理/控制这些对象特有的复杂性?增加一层间接层是软件开发中常见的解决方式。模式定义 为其他对象提供一种代理以控制(隔离,使用接口)对这个对象的访问。结构类图案例分析未使用设计模式class ISubject{public: virtual void process();}原创 2020-05-26 20:54:43 · 132 阅读 · 0 评论 -
设计模式 - 门面模式(Facade)
Facade 门面模式模式定义为子系统中的一组接口提供一个一致(稳定)的界面,Facade模式定义了一个高层接口,这个接口使得这一子系统更加容易使用(复用)。结构类图...原创 2020-01-03 18:51:34 · 298 阅读 · 0 评论 -
设计模式 - 享元模式(Flyweight)
Flyweight(享元模式)模式定义:运用共享技术有效地支持大量细粒度的对象要点总结面对对象很好地解决了抽象性的问题,但是作为一个运行在机器中的程序实体,我们需要考虑对象的代价问题。Flyweight主要解决面对对象的代价问题,一般不触及面对对象的抽象性问题。Flyweight采用对象共享的做法来降低系统中对象的个数,从而降低细粒度对象给系统带来的内存压力。在具体实现方面,要注意对象状...原创 2019-12-25 22:04:11 · 112 阅读 · 0 评论 -
设计模式 - 单件模式(Singleton)
Singleton (单例模式)模式定义:保证一个类仅有一个实例,并提供一个该实例的全局访问点类的定义:class Singleton{private: Singleton(); Singleton(const Singleton &other);public: static Singleton *getInstance(); static Singleton *m_in...原创 2019-12-08 10:36:25 · 216 阅读 · 0 评论 -
设计模式 - 构建器(Builder)
动机 在软件系统中,有时候面临着“一个复杂对象”的创建工作,其通常由各个部分的子对象用一定的算法构成;由于需求的变化,这个复杂对象的各个部分经常面临着剧烈的变化,但是将它们组合在一起的算法却相对稳定。 如何应对这种变化?如何提供一种“封装机制”来隔离出“复杂对象的各个部分”的变化,从而保持系统中的“稳定构建算法”不随着需求改变而改变?模式定义 将一个复杂对象的构建与其表示相分离,使得同样的构建过程(稳定)可以创建不同的表示(变化)。结构类图案例分析未使用构建器class House{原创 2020-05-26 16:21:21 · 166 阅读 · 0 评论 -
设计模式 - 原型模式(Prototype)
动机 在软件系统中,经常面临着“某些结构复杂的对象”的创建工作;由于需求的变化,这些对象经常面临着剧烈的变化,但是它们却拥有比较稳定一致的接口。 如何应对这种变化?如何向“客户程序(使 用这些对象的程序) "隔离出“这些易变对象”,从而使得“依赖这些易变对象的客户程序”不随着需求改变而改变?模式定义 使用原型实例指定创建对象的种类,然后通过拷贝这些原型来创建新的对象。结构类图案例分析未使用原型模式前class MainForm : public Form{public: voi原创 2020-05-26 15:30:24 · 194 阅读 · 0 评论 -
设计模式 - 抽象工厂(Abstract Factory)
动机 在软件系统中,经常面临着“一系列相互依赖的对象”的创建工作;同时,由于需求的变化,往往存在更多系列对象的创建工作。 如何应对这种变化?如何绕过常规的对象创建方法(new),提供一种“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的紧耦合?模式定义 提供一个接口,让该接口负责创建一系列“相关或者相互依赖的对象”,无需指定它们具体的类。结构类图案例分析 以软件中使用数据库类为例,数据库组成可分为三部分Connection、Command、DataReader,市面上数据库原创 2020-05-25 22:28:00 · 182 阅读 · 0 评论 -
设计模式 - 工厂模式(Factory Method)
动机 在软件系统中,经常面临着创建对象的工作;由于需求的变化,需要创建的对象的具体类型经常变化。 如何应对这种变化?如何绕过常规的对象创建方法(new),提供一种“封装机制”来避免客户程序和这种“具体对象创建工作”的紧耦合?模式定义 定义一个用于创建对象的接口,让子类决定实例化哪一个类。Factory Method使得一个类的实例化延迟到子类结构类图案例分析 以下为文件分割器的类设计为例未使用工厂模式前class MainForm : public Form{public:原创 2020-05-25 16:17:06 · 135 阅读 · 0 评论 -
设计模式 - 桥模式(bridge)
动机 由于某些类型的固有的实现逻辑,使得它们具有两个变化的维度,乃至多个纬度的变化。 如何应对这种“多维度的变化”?如何利用面向对象技术来使得类型可以轻松地沿着两个乃至多个方向变化,而不引入额外的复杂度?模式定义 将抽象部分(业务功能)与实现部分(平台实现)分离,使它们都可以独立地变化。结构类图案例分析未使用桥模式前class Messager{public: virtual void Login(string username, string password)=0;原创 2020-05-25 15:22:42 · 249 阅读 · 0 评论 -
设计模式 - 装饰者模式(Decorator)
动机在某些情况下我们可能会“过度地使用继承来扩展对象的功能”,由于继承为类型引入的静态特质,使得这种扩展方式缺乏灵活性;并且随着子类的增多(扩展功能的增多),各种子类的组合(扩展功能的组合)会导致更多子类的膨胀。如何使“对象功能的扩展”能够根据需要来动态地实现?同时避免“扩展功能的增多”带来的子类膨胀问题?从而使得任何“功能扩展变化”所导致的影响将为最低?模式定义 动态(组合)地给一个对象增加一些额外的职责。就增加功能而言,Decorator模式比生成子类(继承)更为灵活(消除重复代码 &am原创 2020-05-24 22:14:07 · 167 阅读 · 0 评论 -
设计模式 - 观察者模式(Observer)
动机 在软件构建过程中,我们需要为某些对象建立一种“通知依赖关系” ——一个对象(目标对象)的状态发生改变,所有的依赖对象(观察者对象)都将得到通知。如果这样的依赖关系过于紧密,将使软件不能很好地抵御变化。 使用面向对象技术,可以将这种依赖关系弱化,并形成一种稳定的依赖关系。从而实现软件体系结构的松耦合。模式定义 定义对象间的一种一对多(变化)的依赖关系,以便当一个对象(Subject)的状态发生改变时,所有依赖于它的对象都得到通知并自动更新。结构体类图案例分析未使用观察者模式前in原创 2020-05-21 22:11:50 · 356 阅读 · 1 评论 -
设计模式 - 策略模式(Strategy)
动机 在软件构建过程中,某些对象使用的算法可能多种多样,经常改变,如果将这些算法都编码到对象中,将会使对象变得异常复杂;而且有时候支持不使用的算法也是一个性能负担。 如何在运行时根据需要透明地更改对象的算法?将算法与对象本身解耦,从而避免上述问题?模式定义 定义一系列算法,把它们一个个封装起来,并且使它们可互相替换(变化)。该模式使得算法可独立于使用它的客户程序(稳定)而变化(扩展,子类化)。结构类图案例分析未使用策略模式前enum TaxBase { CN_Tax, US_Ta原创 2020-05-21 15:54:58 · 159 阅读 · 0 评论 -
设计模式 - 模板模式(Template Method)
模式定义解决问题结构类图案例分析注意要点原创 2020-05-21 13:50:15 · 147 阅读 · 0 评论 -
面向对象的23种设计模式
什么是设计模式每一个模式描述了一个在我们周围不断重复发生的问题以及该问题的解决方案的核心。八大设计原则(1)依赖倒置原则高层模块不应该依赖于底层模块,二者都应该依赖于抽象抽象不应该依赖于实现细节,实现细节不应该依赖抽象(2)开放封闭原则对扩展开放,对更改封闭类模块应该是可扩展的,但是不可修改(3)单一职责原则一个类应该仅有一个引起它变化的原因变化的方向隐含着类的责任(4)替换原则子类必须能够替换它们的基类继承表达类型抽象(5)接口隔离原则不应该强迫客户程序依原创 2020-05-20 22:58:35 · 842 阅读 · 0 评论