比特飞

文章末尾附带GitHub开源下载地址。设计模式概述20世纪80年代，四人组(Gang of Four or GoF)将常用的23种软件设计模式进行了归纳整理，自此标志着软件设计模式的正式诞生。它旨在用“模式”来统一和沟通面向对象思想在分析、设计和解决问题之间的鸿沟。在未来的几十年里，它被证明是行之有效的软件开发准则，是通向软件架构师的必经之路，是软件开发领域的“葵花宝典”。设计模式是一套被反复使用的、经过合理分类的、用于提高开发效率的设计经验的总结。本系列文章将以C#语言来系统的介绍这23种常用

访问者模式（Vistor Pattern）访问者模式属于行为型模式，表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素类的前提下定义作用于这些元素的新操作。结构对象是使用访问者模式必备条件，而且这个结构对象必须存在遍历自身各个对象的方法。角色：1、抽象访问者（Visitor）为该对象结构中具体元素角色声明一个访问操作接口。该操作接口的名字和参数标识了发送访问请求...

模板方法模式（Template Method Pattern）模板方法模式属于行为型模式，定义一个模板结构，将具体内容延迟到子类去实现。在不改变模板结构的前提下在子类中重新定义模板中的内容。角色：1、抽象类（Abstract Class）实现了模板方法，定义了算法的框架；2、具体类（Concrete Class)实现抽象类中的抽象方法，以完成完整的算法。命名空间...

策略模式（Stragety Pattern）策略模式属于行为型模式，它定义了一系列的算法，并将每一个算法封装起来，而且使他们可以相互替换，让算法独立于使用它的客户而独立变化。使用策略模式可以把行为和环境分割开来。环境类负责维持和查询行为类，各种算法则在具体策略类中提供。角色：1、抽象策略（Strategy）这是一个抽象角色，通常由一个接口或抽象类实现。此角色给出所有的具体策略类...

状态模式（State Pattern）状态模式属于行为型模式，它允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。状态模式主要解决的是当控制一个对象状态的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同状态的一系列类中，可以把复杂的判断逻辑简化。角色：1、抽象状态（State）状态模式的核心基类，它表示某种对象的不同状态；2、具体状态（Con...

观察者模式（ObserverPattern）观察者模式属于行为型模式，有时又被称为模型-视图（Model-View）模式、发布-订阅（Publish-Subscribe）模式、源-监听器（Source-Listener）模式或从属者（Dependents）模式。观察者模式完美的将观察者和被观察的对象分离开，并在目标物件状态改变时主动向观察者发出通知（接口方法、抽象方法、委托、事件）。观察...

备忘录模式（Memento Pattern）备忘录模式属于行为型模式，在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。备忘录模式为我们提供了“后悔药”的机制，为我们在需要的时候，可以将对对象的修改撤销甚至重做。角色：1、原发器（Originator）创建一个备忘录，用以记录当前时刻它的内部状态，在需要时使用备...

中介者模式（Mediator Pattern）中介者模式属于行为型模式，它包装了一系列对象相互作用的方式，使得这些对象不必相互明显作用，从而使它们可以松散耦合。当某些对象之间的作用发生改变时，不会立即影响其他的一些对象之间的作用，保证这些作用可以彼此独立的变化。角色：1、抽象中介者(Mediator)：定义统一的接口用于各同事角色之间的通信，其中主要方法是一个（或多个）事件方法...

迭代器模式（Iterator Pattern）迭代器模式属于行为型模式，它提供一种方法顺序访问一个聚合对象中的各种元素，而又不暴露该对象的内部表示，这样既可以做到不暴露集合的内部结构，又可让外部代码透明地访问集合内部的数据。角色：1、迭代器（Iterator）迭代器角色负责定义访问和遍历元素的接口；2、具体迭代器（Concrete Iteraror）具体迭代器角色实现了迭代...

解释器模式（Interpreter Pattern）解释器模式属于行为型模式，给定一个语言，定义它的文法表示，并定义一个解释器，这个解释器使用该标识来解释语言中的句子。解释器模式提供了评估语言的语法或表达式的方式。这种模式实现了一个表达式接口，该接口解释一个特定的上下文。这种模式被广泛地应用在 SQL 解析、符号处理引擎等领域。角色：1、抽象表达式（Expression）声明一...

命令模式（Command Pattern）命令模式属于行为型模式，它尝试将一个请求封装成一个对象，从而使您可以用不同的请求对客户进行参数化。在该设计模式中，请求以命令的形式包裹在对象中并传给调用对象。调用对象寻找可以处理该命令的合适的对象，并把该命令传给相应的对象请求执行。角色：1、抽象命令（Command）定义命令的接口，声明命令执行的方法；2、具体命令（Concrete...

职责链模式（Chain of Responsibility Pattern）职责链模式属于行为型模式，它为请求创建了一个接收者对象的链。这种模式给予一个具体请求的类型，对请求的发送者和接收者进行解耦。通常有2种方法来实现该模式。第1种是每个接收者都包含对下一个接收者的引用，以便在不能处理该请求时，转派请求至下一个接收者。第2个方法是引入中间链条类，由中间件负责转派请求。第一种方法的实现较为...

代理模式（Proxy Pattern）代理模式属于结构型模式，为其他对象提供一种代理以控制对这个对象的访问。在某些情况下，一个对象不适合或者不能直接引用另一个对象，而代理对象可以在客户端和目标对象之间起到中介的作用。角色：1、抽象主题（Subject）通过接口或抽象类声明真实角色实现的业务方法；2、代理主题（Proxy）真实角色的代理，通过真实角色的业务逻辑方法来实现抽...

享元模式（Flyweight Pattern）享元模式属于结构型模式，它以共享的方式高效的支持大量的细粒度对象。通过复用内存中已存在的对象，降低系统创建对象实例的性能消耗。享元模式尝试重用现有的同类对象，如果未找到匹配的对象，则创建新对象，如果找到对象，则直接返回。角色：1、抽象享元（Flyweight）它是所有具体享元类的抽象基类，为其子类规定出需要实现的公共接口；2、...

外观模式（Facade Pattern）外观模式属于结构型模式，它隐藏了系统的复杂性，并向客户端提供了一个客户端可以访问系统的接口。为子系统中的一组接口提供了一个统一的访问接口，这个接口使得子系统更容易被访问或者使用。角色：1、外观角色（Facade）外观模式的核心，它被客户角色调用，它熟悉子系统的各项功能，可以在内部根据需求预定几种功能的组合；2、子系统角色（SubSys...

装饰者模式（Decorator Pattern）装饰者模式属于结构型模式，装饰模式是在不必改变原类文件和使用继承的情况下，动态地扩展一个对象的功能。装饰者模式通过创建一个包装对象（wrapper），也就是用装饰来包裹真实的对象。角色：1、抽象构件（Component）给出一个抽象接口，以规范准备接收附加责任的对象；2、具体构件（Concrete Component）定义...

组合模式（Composite Pattern）组合模式属于结构型模式，将对象组合成树形结构以表示“部分-整体”的层次结构，组合模式使得用户对单个对象和组合对象的使用具有一致性。组合模式有时候又叫做部分-整体模式，它使我们树型结构的问题中，模糊了简单元素和复杂元素的概念，客户程序可以像处理简单元素一样来处理复杂元素，从而使得客户程序与复杂元素的内部结构解耦。角色：1、抽象构件（Com...

桥接模式（Bridge Pattern）桥接模式属于结构型模式，它将抽象部分与它的实现部分分离，使它们都可以相互独立地变化。利用面向对象的技术来使得某类型能够轻松的沿着多个方向进行变化，而又不引入额外的复杂度，这就是桥接模式的核心意义。角色：1、抽象（Abstraction）定义抽象接口，该接口中包含实现具体行为、具体特征的Implementor接口；2、扩充抽象（Refi...

适配器模式（Adapter Pattern）适配器模式属于结构型模式，把一个类的接口变成客户端所期待的另一种接口，从而使原本接口不匹配而无法一起工作的两个类能够在一起工作。适配器模式又可以分为4种类型，类适配器模式、对象适配器模式、单接口适配器模式（缺省适配器模式）和双向适配器模式。后2种模式的实现比较复杂并且在实际开发过程中很少使用，故本博文只讨论前2种模式。角色：1、抽象目标(...

单例模式（Singleton Pattern）单例模式属于创建型模式，保证一个类仅有一个实例，并提供一个访问它的全局访问点。一个类有且仅有一个实例，并且自行实例化向整个系统提供。角色：1、单例类（Singleton）保证唯一并提供全局访问点的单例类。命名空间SingletonPattern中包含7个单例类，本案例将介绍这7种常见的单例实现方法。namespace ...

原型模式（Prototype Pattern）原型模式属于创建型模式，使用原型实例指定待创建对象的类型，并且通过复制这个原型来创建新的对象。原型模式关注的是大量相同或相似对象的创建问题。应用原型模式就是建立一个原型，然后通过对原型来进行复制的方法，产生一个和原型相同或相似的新对象。角色：1、抽象原型（Prototype）声明一个克隆自身的接口，通常名为Clone；2、具体原...

建造者模式（Builder Pattern）建造者模式属于创建型模式，将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。建造者模式使用多个简单的对象一步一步构建成一个复杂的对象。角色：1、抽象建造者（Builder）给出一个抽象结论，以规范产品对象的各个组成成分的建造。这个接口规定要实现复杂对象的那些部分的创建，并不涉及具体的对象部件的创建；2、具体...

设计模式概述20世纪80年代，四人组(Gang of Four orGoF)将常用的23种软件设计模式进行了归纳整理，自此标志着软件设计模式的正式诞生。它旨在用“模式”来统一和沟通面向对象思想在分析、设计和解决问题之间的鸿沟。在未来的几十年里，它被证明是行之有效的软件开发准则，是通向软件架构师的必经之路，是软件开发领域的“葵花宝典”。设计模式是一套被反复使用的、经过合理分...

单一职责原则（Single Responsibility Principle or SRP）一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中。SRP：Every object should have a single responsibility,and that responsibility should be entirely encapsulated by the cl...

开放闭合原则（Open-Closed Principle or OCP）开放闭合原则又叫开闭原则，即软件实体应当对扩展开放，对修改封闭。OCP：Software entities should be open for extension,but closed for madification.开闭原则就是指软件实体应当尽量保证在不修改原有代码的情况下，对软件进行扩展。开闭原则是面向对象...

里氏替换原则（Liskov Substitution Principle or LSP）所有引用基类的地方必须透明的使用其子类的对象。LSP：Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it....

依赖倒置原则（Dependence Inversion Principle DIP ）高层模块不应该依赖低层模块，他们都应该依赖于抽象；抽象不应该依赖于细节，细节应该依赖于抽象。简单的定义为：面向接口（抽象）编程，不要面向实现编程。DIP：High level modules should not depend upon low level modules,Both should de...

接口隔离原则（Interface Segregation Principle or ISP）客户端不应该依赖它不需要的接口。ISP：Clients should not be forced to depend upon interfaces that they don’t use.一个类对另外一个类的依赖性应当是建立在最小的接口上的。示例：public abstract c...

合成复用原则（Composite Reuse Principle or CRP）尽量使用对象组合，而不是继承来达到复用的目的。CRP：Favor polymorphic composition of objects over inheritance as a reuse mechanism.合成复用原则是鼓励优先使用对象的组合，而不是使用继承。示例：public abstra...

迪米特法则（Law of Demeter or LoD）一个软件实体应当尽可能少的与其他实体发生相互作用。每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。LoD：Each unit should have only limited knowledge about other units: only units "closely" related to ...

信息专家原则（Information ExpertPrinciple）（1）问题给对象分配职责的通用原则是什么？（2）方案将职责分配给拥有履行一个职责所必需信息的类，即信息专家。（3）分析信息专家原则是面向对象设计的最基本原则。通俗点来讲，就是一个类只做自己应该做的事。在系统设计时，需要将职责分配给具有实现这个职责所需要信息的类。信息专家原则对应于面向对象设计原则中的单一...

创造者原则（CreatorPrinciple）（1）问题谁应该负责产生类的实例？（2）方案如果符合下面的一个或者多个条件，则可将创建类A实例的职责分配给类B：B包含A； B聚合A； B拥有初始化A的数据并在创建类A的实例时将数据传递给类A； B记录A的实例； B频繁使用A。此时，我们称类B是类A对象的创建者。如果符合多个条件，类B聚合或者包含类A的条件优先。（3...

低耦合原则（Low CouplingPrinciple）（1）问题怎样支持低的依赖性，减少变更带来的影响，提高重用性？（2）方案分配一个职责，使得保持低耦合度。（3）分析耦合是评价一个系统中各个元素之间连接或依赖强弱关系的尺度，具有低耦合的元素不过多依赖其他元素。此处的元素可以是类，也可以是模块、子系统或者系统。具有高耦合的类过多地依赖其他类，这种设计将会导致：一个类的修...

高内聚原则（High CohesionPrinciple）（1）问题怎样使得复杂性可管理？（2）方案分配一个职责，使得保持高内聚。（3）分析内聚是评价一个元素的职责被关联和关注强弱的尺度。如果一个元素具有很多紧密相关的职责，而且只完成有限的功能，则这个元素就具有高内聚性。此处的元素可以是类，也可以是模块、子系统或者系统。在一个低内聚的类中会执行很多互不相关的操作，这将...

控制器原则（ControllerPrinciple）（1）问题谁应该负责处理一个输入系统事件？（2）方案把接收或者处理系统事件消息的职责分配给一个类。这个类可以代表：整个系统、设备或者子系统； 系统事件发生时对应的用例场景，在相同的用例场景中使用相同的控制器来处理所有的系统事件。（3）分析一个控制器是负责接收或者处理系统事件的非图形用户界面对象。一个控制器定义一组系统...

多态原则（PolymorphismPrinciple）（1）问题1、如何处理基于类型的不同选择？2、如何创建可嵌入的软件组件？（2）方案当相关选择或行为随类型（类）变化而变化时，用多态操作为行为变化的类型分配职责。（3）分析由条件变化引发同一类型的不同行为是程序的一个基本主题。如果用if-else或switch-case等条件语句来设计程序，当系统发生变化时必须修改程序...

纯虚构原则（Pure FabricationPrinciple）（1）问题当不想破坏高内聚和低耦合的设计原则时，谁来负责处理这种情况？（2）方案将一组高内聚的职责分配给一个虚构的或处理方便的“行为”类，它并不是问题域中的概念，而是虚构的事务，以达到支持高内聚、低耦合和重用的目的。（3）分析纯虚构模式用于解决高内聚和低耦合之间的矛盾，它要求将一部分类的职责转移到纯虚构类中，...

中介原则（IndirectionPrinciple）（1）问题1、如何分配职责以避免两个（或多个）事物之间的直接耦合？2、如何解耦对象以降低耦合度并提高系统的重用性？（2）方案分配职责给中间对象以协调组件或服务之间的操作，使得它们不直接耦合。中间对象就是在其他组件之间建立的中介。（3）分析要避免对象之间的直接耦合，最常用的做法是在对象之间引入一个中间对象或中介对象，通过...

受保护变量原则（Protected VariationsPrinciple）（1）问题如何分配职责给对象、子系统和系统，使得这些元素中的变化或不稳定的点不会对其他元素产生不利影响？（2）方案找出预计有变化或不稳定的元素，为其创建稳定的“接口”而分配职责。（3）分析受保护变化模式简称PV，它是大多数编程和设计的基础，是模式的基本动机之一，它使系统能够适应和隔离变化。它与面向...

简单工厂模式（Simple Factory Pattern）简单工厂模式属于创建型模式，又叫做静态工厂方法（Static Factory Method）模式，但不属于23种GoF设计模式之一。学习简单工厂模式是学习其它工厂模式的前提条件。简单工厂模式是由一个工厂对象决定创建出哪一种产品类的实例。简单工厂模式是工厂模式家族中最简单实用的模式，可以理解为是不同工厂模式的一个特殊实现。角色：...