Design Pattern guru · GitBook - Introduction

design pattern by guru. 设计模式概念最初是由四人组系统提出的，在面向对象编程过程中总结出来的一套设计方法论。

The idea was picked up by four authors: Erich ... Introduction Linux linuxbasis linuxfilesystem linuxcommand linuxfilesystem Awesome git gitbook Docker dockerbasis dockerswarm dockerfile dockercomposefile dockerpractice HTML Javascript canvas react immer tools babel gulp webpack Reading CSSworld DesignPatternguru compilers tcpip nettyinaction Blog myknowledgemap cpuandkernal linuxselect threadvsprocess cssinjs PublishedwithGitBook DesignPatternguru designpatternbyguru 设计模式概念最初是由四人组系统提出的，在面向对象编程过程中总结出来的一套设计方法论。

Theideawaspickedupbyfourauthors:ErichGamma,JohnVlissides,RalphJohnson,andRichardHelm.In1994,theypublishedDesignPatterns:ElementsofReusableObject-OrientedSoftware,inwhichtheyappliedtheconceptofdesignpatternstoprogramming. 具体在我写代码的过程中，很少去刻意的使用某个设计模式，遵循高内聚、低耦合，一个方法只做一件事，相同的逻辑提炼出来做到复用，方法尽量短小精简易读，这些都做好了，其实很自然的就会用到设计模式。

艺术来源生活，设计模式不是凭空出现的，是在长期的编码过程中很自然的提炼出来的。

所以为啥还要系统的学习设计模式呢？ Designpatternsareatoolkitoftriedandtestedsolutionstocommonproblemsinsoftwaredesign. Designpatternsdefineacommonlanguagethatyouandyourteammatescanusetocommunicatemoreefficiently 本来大部分都是对原文的摘抄，方便我本地查看。

Creationalpatterns创建模式 Factorymethod工厂方法 产品（Product）将会对接口进行声明。

对于所有由创建者及其子类构建的对象，这些接口都是通用的。

具体产品（ConcreteProducts）是产品接口的不同实现。

创建者（Creator）类声明返回产品对象的工厂方法。

该方法的返回对象类型必须与产品接口相匹配。

你可以将工厂方法声明为抽象方法，强制要求每个子类以不同方式实现该方法。

或者，你也可以在基础工厂方法中返回默认产品类型。

注意，尽管它的名字是创建者，但他最主要的职责并不是创建产品。

一般来说，创建者类包含一些与产品相关的核心业务逻辑。

工厂方法将这些逻辑处理从具体产品类中分离出来。

打个比方，大型软件开发公司拥有程序员培训部门。

但是，这些公司的主要工作还是编写代码，而非生产程序员。

具体创建者（ConcreteCreators）将会重写基础工厂方法，使其返回不同类型的产品。

注意，并不一定每次调用工厂方法都会创建新的实例。

工厂方法也可以返回缓存、对象池或其他来源的已有对象。

创建产品和实际使用产品的代码分离，每一个产品对应一个具体的创建者实例 具体的创建者（ConcreteCreator）将重写基础工厂方法，返回不同的产品。

工厂方法不一定要返回新的实例，比如可以返回缓存对象。

Abstractfactory抽象工厂 示例如下 保证同一工厂生产的产品能匹配 避免客户端和具体产品代码的耦合 缺点：需要引入众多的接口和类 Builder生成器模式 生成器（Builder）接口声明在所有类型生成器中通用的产品构造步骤。

具体生成器（ConcreteBuilders）提供构造过程的不同实现。

具体生成器也可以构造不遵循通用接口的产品。

产品（Products）是最终生成的对象。

由不同生成器构造的产品无需属于同一类层次结构或接口。

主管（Director）类定义调用构造步骤的顺序，这样你就可以创建和复用特定的产品配置。

客户端（Client）必须将某个生成器对象与主管类关联。

一般情况下，你只需通过主管类构造函数的参数进行一次性关联即可。

此后主管类就能使用生成器对象完成后续所有的构造任务。

但在客户端将生成器对象传递给主管类制造方法时还有另一种方式。

在这种情况下，你在使用主管类生产产品时每次都可以使用不同的生成器。

Prototype原型模式 clone Singleton单例模式 Structuralpatterns结构模式 Adaptor适配器模式 客户端（Client）是包含当前程序业务逻辑的类。

客户端接口（ClientInterface）描述了其他类与客户端代码合作时必须遵循的协议。

服务（Service）中有一些功能类（通常来自第三方或遗留系统）。

客户端与其接口不兼容，因此无法直接调用其功能。

适配器（Adapter）是一个可以同时与客户端和服务交互的类：它在实现客户端接口的同时封装了服务对象。

适配器接受客户端通过适配器接口发起的调用，并将其转换为适用于被封装服务对象的调用。

客户端代码只需通过接口与适配器交互即可，无需与具体的适配器类耦合。

因此，你可以向程序中添加新类型的适配器而无需修改已有代码。

这在服务类的接口被更改或替换时很有用：你无需修改客户端代码就可以创建新的适配器类。

Bridget桥接模式 抽象部分（Abstraction）提供高层控制逻辑，依赖于完成底层实际工作的实现对象。

实现部分（Implementation）为所有具体实现声明通用接口。

抽象部分仅能通过在这里声明的方法与实现对象交互。

具体实现（ConcreteImplementations）中包括特定于平台的代码。

精确抽象（RefinedAbstraction）提供控制逻辑的变体。

与其父类一样，它们通过通用实现接口与不同的实现进行交互。

通常情况下，客户端（Client）仅关心如何与抽象部分合作。

但是，客户端需要将抽象对象与一个实现对象连接起来。

抽象部分可以列出和实现部分一样的方法，但是抽象部分通常声明一些复杂行为，这些行为依赖于多种由实现部分声明的原语操作。

//“抽象部分”定义了两个类层次结构中“控制”部分的接口。

它管理着一个指向“实 //现部分”层次结构中对象的引用，并会将所有真实工作委派给该对象。

classRemoteControlis protectedfielddevice:Device constructorRemoteControl(device:Device)is this.device=device methodtogglePower()is if(device.isEnabled())then device.disable() else device.enable() methodvolumeDown()is device.setVolume(device.getVolume()-10) methodvolumeUp()is device.setVolume(device.getVolume()+10) methodchannelDown()is device.setChannel(device.getChannel()-1) methodchannelUp()is device.setChannel(device.getChannel()+1) //你可以独立于设备类的方式从抽象层中扩展类。

classAdvancedRemoteControlextendsRemoteControlis methodmute()is device.setVolume(0) //“实现部分”接口声明了在所有具体实现类中通用的方法。

它不需要与抽象接口相 //匹配。

实际上，这两个接口可以完全不一样。

通常实现接口只提供原语操作，而 //抽象接口则会基于这些操作定义较高层次的操作。

interfaceDeviceis methodisEnabled() methodenable() methoddisable() methodgetVolume() methodsetVolume(percent) methodgetChannel() methodsetChannel(channel) //所有设备都遵循相同的接口。

classTvimplementsDeviceis //... classRadioimplementsDeviceis //... //客户端代码中的某个位置。

tv=newTv() remote=newRemoteControl(tv) remote.togglePower() radio=newRadio() remote=newAdvancedRemoteControl(radio) Composite组合模式 组件（Component）接口描述了树中简单项目和复杂项目所共有的操作。

叶节点（Leaf）是树的基本结构，它不包含子项目。

一般情况下，叶节点最终会完成大部分的实际工作，因为它们无法将工作指派给其他部分。

容器（Container）——又名“组合（Composite）”——是包含叶节点或其他容器等子项目的单位。

容器不知道其子项目所属的具体类，它只通过通用的组件接口与其子项目交互。

容器接收到请求后会将工作分配给自己的子项目，处理中间结果，然后将最终结果返回给客户端。

客户端（Client）通过组件接口与所有项目交互。

因此，客户端能以相同方式与树状结构中的简单或复杂项目交互。

几何形状编辑器示例 Decorator装饰模式 部件（Component）声明封装器和被封装对象的公用接口。

具体部件（ConcreteComponent）类是被封装对象所属的类。

它定义了基础行为，但装饰类可以改变这些行为。

基础装饰（BaseDecorator）类拥有一个指向被封装对象的引用成员变量。

该变量的类型应当被声明为通用部件接口，这样它就可以引用具体的部件和装饰。

装饰基类会将所有操作委派给被封装的对象。

具体装饰类（ConcreteDecorators）定义了可动态添加到部件的额外行为。

具体装饰类会重写装饰基类的方法，并在调用父类方法之前或之后进行额外的行为。

客户端（Client）可以使用多层装饰来封装部件，只要它能使用通用接口与所有对象互动即可。

聚合（或组合）组合是许多设计模式背后的关键原则（包括装饰在内）。

封装器是装饰模式的别称，这个称谓明确地表达了该模式的主要思想。

​“封装器”是一个能与其他“目标”对象连接的对象。

封装器包含与目标对象相同的一系列方法，它会将所有接收到的请求委派给目标对象。

但是，封装器可以在将请求委派给目标前后对其进行处理，所以可能会改变最终结果。

facade外观模式 外观模式是一种结构型设计模式，能为程序库、框架或其他复杂类提供一个简单的接口。

外观（Facade）提供了一种访问特定子系统功能的便捷方式，其了解如何重定向客户端请求，知晓如何操作一切活动部件。

创建附加外观（AdditionalFacade）类可以避免多种不相关的功能污染单一外观，使其变成又一个复杂结构。

客户端和其他外观都可使用附加外观。

复杂子系统（ComplexSubsystem）由数十个不同对象构成。

如果要用这些对象完成有意义的工作，你必须深入了解子系统的实现细节，比如按照正确顺序初始化对象和为其提供正确格式的数据。

子系统类不会意识到外观的存在，它们在系统内运作并且相互之间可直接进行交互。

客户端（Client）使用外观代替对子系统对象的直接调用。

flyweight 仅在程序必须支持大量对象且没有足够的内存容量时使用享元模式。

proxy代理模式 服务接口（ServiceInterface）声明了服务接口。

代理必须遵循该接口才能伪装成服务对象。

服务（Service）类提供了一些实用的业务逻辑。

代理（Proxy）类包含一个指向服务对象的引用成员变量。

代理完成其任务（例如延迟初始化、记录日志、访问控制和缓存等）后会将请求传递给服务对象。

通常情况下，代理会对其服务对象的整个生命周期进行管理。

客户端（Client）能通过同一接口与服务或代理进行交互，所以你可在一切需要服务对象的代码中使用代理。

Behavioralpatterns行为模式 Chain责任链模式 处理者（Handler）声明了所有具体处理者的通用接口。

该接口通常仅包含单个方法用于请求处理，但有时其还会包含一个设置链上下个处理者的方法。

基础处理者（BaseHandler）是一个可选的类，你可以将所有处理者共用的样本代码放置在其中。

通常情况下，该类中定义了一个保存对于下个处理者引用的成员变量。

客户端可通过将处理者传递给上个处理者的构造函数或设定方法来创建链。

该类还可以实现默认的处理行为：确定下个处理者存在后再将请求传递给它。

具体处理者（ConcreteHandlers）包含处理请求的实际代码。

每个处理者接收到请求后，都必须决定是否进行处理，以及是否沿着链传递请求。

处理者通常是独立且不可变的，需要通过构造函数一次性地获得所有必要地数据。

客户端（Client）可根据程序逻辑一次性或者动态地生成链。

值得注意的是，请求可发送给链上的任意一个处理者，而非必须是第一个处理者。

Command命令模式 发送者（Sender）——亦称“触发者（Invoker）”——类负责对请求进行初始化，其中必须包含一个成员变量来存储对于命令对象的引用。

发送者触发命令，而不向接收者直接发送请求。

注意，发送者并不负责创建命令对象：它通常会通过构造函数从客户端处获得预先生成的命令。

命令（Command）接口通常仅声明一个执行命令的方法。

具体命令（ConcreteCommands）会实现各种类型的请求。

具体命令自身并不完成工作，而是会将调用委派给一个业务逻辑对象。

但为了简化代码，这些类可以进行合并。

接收对象执行方法所需的参数可以声明为具体命令的成员变量。

你可以将命令对象设为不可变，仅允许通过构造函数对这些成员变量进行初始化。

接收者（Receiver）类包含部分业务逻辑。

几乎任何对象都可以作为接收者。

绝大部分命令只处理如何将请求传递到接收者的细节，接收者自己会完成实际的工作。

客户端（Client）会创建并配置具体命令对象。

客户端必须将包括接收者实体在内的所有请求参数传递给命令的构造函数。

此后，生成的命令就可以与一个或多个发送者相关联了。

java代码示例： 创建Command抽象类，传入Editor，和定义execute()方法 复制、剪切、粘贴、撤销四个按钮分别实现了Command类，如果execute()返回true，则将当前命令放入CommandHistory栈里面 复制按钮将editor将选中内容设置为剪切板内容，并返回false 剪切先备份当前内容，同时设置剪切板的内容为选中内容，然后更新Editor的内容，同时返回true 粘贴命令将剪切板内容插入到Editor指定位置，并返回true 撤销将备份内容拿出来 Iterator迭代器模式 迭代器（Iterator）接口声明了遍历集合所需的操作：获取下一个元素、获取当前位置和重新开始迭代等。

具体迭代器（ConcreteIterators）实现遍历集合的一种特定算法。

迭代器对象必须跟踪自身遍历的进度。

这使得多个迭代器可以相互独立地遍历同一集合。

集合（Collection）接口声明一个或多个方法来获取与集合兼容的迭代器。

请注意，返回方法的类型必须被声明为迭代器接口，因此具体集合可以返回各种不同种类的迭代器。

具体集合（ConcreteCollections）会在客户端请求迭代器时返回一个特定的具体迭代器类实体。

你可能会琢磨，剩下的集合代码在什么地方呢？不用担心，它也会在同一个类中。

只是这些细节对于实际模式来说并不重要，所以我们将其省略了而已。

客户端（Client）通过集合和迭代器的接口与两者进行交互。

这样一来客户端无需与具体类进行耦合，允许同一客户端代码使用各种不同的集合和迭代器。

Mediator中介者模式 组件（Component）是各种包含业务逻辑的类。

每个组件都有一个指向中介者的引用，该引用被声明为中介者接口类型。

组件不知道中介者实际所属的类，因此你可通过将其连接到不同的中介者以使其能在其他程序中复用。

中介者（Mediator）接口声明了与组件交流的方法，但通常仅包括一个通知方法。

组件可将任意上下文（包括自己的对象）作为该方法的参数，只有这样接收组件和发送者类之间才不会耦合。

具体中介者（ConcreteMediator）封装了多种组件间的关系。

具体中介者通常会保存所有组件的引用并对其进行管理，甚至有时会对其生命周期进行管理。

组件并不知道其他组件的情况。

如果组件内发生了重要事件，它只能通知中介者。

中介者收到通知后能轻易地确定发送者，这或许已足以判断接下来需要触发的组件了。

对于组件来说，中介者看上去完全就是一个黑箱。

发送者不知道最终会由谁来处理自己的请求，接收者也不知道最初是谁发出了请求。

Observer观察者模式 发布者（Publisher）会向其他对象发送值得关注的事件。

事件会在发布者自身状态改变或执行特定行为后发生。

发布者中包含一个允许新订阅者加入和当前订阅者离开列表的订阅构架。

当新事件发生时，发送者会遍历订阅列表并调用每个订阅者对象的通知方法。

该方法是在订阅者接口中声明的。

订阅者（Subscriber）接口声明了通知接口。

在绝大多数情况下，该接口仅包含一个update更新方法。

该方法可以拥有多个参数，使发布者能在更新时传递事件的详细信息。

具体订阅者（ConcreteSubscribers）可以执行一些操作来回应发布者的通知。

所有具体订阅者类都实现了同样的接口，因此发布者不需要与具体类相耦合。

订阅者通常需要一些上下文信息来正确地处理更新。

因此，发布者通常会将一些上下文数据作为通知方法的参数进行传递。

发布者也可将自身作为参数进行传递，使订阅者直接获取所需的数据。

客户端（Client）会分别创建发布者和订阅者对象，然后为订阅者注册发布者更新。

State状态模式 上下文（Context）保存了对于一个具体状态对象的引用，并会将所有与该状态相关的工作委派给它。

上下文通过状态接口与状态对象交互，且会提供一个设置器用于传递新的状态对象。

状态（State）接口会声明特定于状态的方法。

这些方法应能被其他所有具体状态所理解，因为你不希望某些状态所拥有的方法永远不会被调用。

声明了所有状态下的方法。

具体状态（ConcreteStates）会自行实现特定于状态的方法。

为了避免多个状态中包含相似代码，你可以提供一个封装有部分通用行为的中间抽象类。

状态对象可存储对于上下文对象的反向引用。

状态可以通过该引用从上下文处获取所需信息，并且能触发状态转移。

上下文和具体状态都可以设置上下文的下个状态，并可通过替换连接到上下文的状态对象来完成实际的状态转换。

Strategy策略模式 策略模式建议找出负责用许多不同方式完成特定任务的类，然后将其中的算法抽取到一组被称为策略的独立类中。

上下文（Context）维护指向具体策略的引用，且仅通过策略接口与该对象进行交流。

l 策略（Strategy）接口是所有具体策略的通用接口，它声明了一个上下文用于执行策略的方法。

具体策略（ConcreteStrategies）实现了上下文所用算法的各种不同变体。

当上下文需要运行算法时，它会在其已连接的策略对象上调用执行方法。

上下文不清楚其所涉及的策略类型与算法的执行方式。

客户端（Client）会创建一个特定策略对象并将其传递给上下文。

上下文则会提供一个设置器以便客户端在运行时替换相关联的策略。

Visitor访问者模式 访问者（Visitor）接口声明了一系列以对象结构的具体元素为参数的访问者方法。

如果编程语言支持重载，这些方法的名称可以是相同的，但是其参数一定是不同的。

具体访问者（ConcreteVisitor）会为不同的具体元素类实现相同行为的几个不同版本。

元素（Element）接口声明了一个方法来“接收”访问者。

该方法必须有一个参数被声明为访问者接口类型。

具体元素（ConcreteElement）必须实现接收方法。

该方法的目的是根据当前元素类将其调用重定向到相应访问者的方法。

请注意，即使元素基类实现了该方法，所有子类都必须对其进行重写并调用访问者对象中的合适方法。

客户端（Client）通常会作为集合或其他复杂对象（例如一个组合树）的代表。

客户端通常不知晓所有的具体元素类，因为它们会通过抽象接口与集合中的对象进行交互。

参考 designgurudesignpattern resultsmatching"" Noresultsmatching""