Pattern - jwyx/ForFun GitHub Wiki
<<大话设计模式>>
High cohesion and low coupling
extensible，reusable，flexible，maintainable
// 很多if-else, switch的考虑使用多态, 此时将各分支抽象为类
面向对象的编程，并不是类越多越好，类的划分是为了封装，但分类的基础是抽象，具有相同属性和功能的对象的抽象集合才是类。
对象的继承关系时在编译时就定义好了，所以无法在运行时改变从父类继承的实现。
子类的实现与它的父类有非常强的依赖关系，以至于父类实现中的任何变化必然会导致子类发生变化。
当你需要复用子类时，如果继承下来的实现不适合解决新的问题，则父类必须重写或者其他更适合的类替换。
这种依赖关系限制了灵活性并最终限制了复用性。
合成composition／聚合aggregation复用原则
尽量使用合成／聚合，尽量不要使用类继承。
聚合表示一种弱的‘拥有’关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分；
合成则是一种强的‘拥有’关系，体现了严格的部分和整体的关系，部分和整体的生命周期一样。
优先使用对象的合成／聚合将有助于你保持每个类被封装，并被集中在单个任务上。
这样类和类继承层次会保持较小规模，并且不太可能增长为不可控制的庞然大物。
Single responsibility principle [SRP]
就一个类而言，应该仅有一个引起它变化的原因。(功能变化)
如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。
这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。
软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。
如何判断，如果你想到多于一个的动机去改变一个类，那么这个类就是具有多于一个的职责。
Open-Closed principle [OCP]
软件实体（类，模块，函数等）应该可以扩展，但是不可修改。
Open for extension, and closed for modification.
无论模块多么封闭，都会存在一些无法对之封闭的变化。既然不可能完全封闭，设计人员必须对他设计的模块应该对哪些变化封闭作出选择。
他必须猜测出最有可能发生的变化种类，然后构造抽象来隔离那些变化。
在我们最初编写代码时，假设变化不会发生。当变化发生时，我们就创建抽象来隔离以后发生的同类变化。
面对需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码。
开放－封闭原则是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处：可维护，可扩展，可复用，灵活性好.
开发人员应该仅对程序中呈现出频繁变化的那些部分作出抽象，然而，对于应用程序中每个部分都刻意地进行抽象同样不是一个好主意。
拒绝不成熟的抽象和抽象本身一样重要。
依赖倒转原则 Dependence Inversion Principle[DIP]
抽象不应该依赖细节，细节应该依赖抽象。
针对接口编程，不要对实现编程。
高层模块不应该依赖低层模块。两个都应该依赖抽象。（参考计算机的模块）
抽象不应该依赖细节。细节应该依赖抽象。
依赖倒转其实可以说是面向对象设计的标志，用哪种语言来编写程序不重要，如果编写时考虑的都是如何针对抽象编程而不是针对细节编程，
即程序中所有的依赖关系都时终止于抽象类或接口，那么就是面向对象设计，反之就是过程化的设计
里氏代换原则Liskov Substitution Principle [LSP]
为什么依赖抽象的接口或抽象类就不怕更改？
子类型必须能够替换掉它们的父类型。
只有当子类可以替换掉父类，软件单位的功能不受到影响时，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为。
正由于子类的可替换性才使得使用父类类型的模块在无需修改的情况下可以进行扩展。
迪米特法则 law of Demeter, LoD / Least Knowledge Principle
如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的互相作用。如果其中一个类需要调用另一个类的某一个方法的话，
可以通过第三者转发这个调用。
强调在类的设计上，每一个类都应当尽量降低成员的访问权限。根本思想强调了类之间的松耦合。
UML
类: 矩形框；分为三层
一层: 类的名称，如果是抽象类，则用斜体显式
二层: 类的特性，通常就是字段和属性
三层: 类的操作，通常就是方法或行为
+: public
-: private
#: protected
接口: 矩形图；
一层: <<interface>> 和 接口名称
二层: 接口方法
类之间 和 类与接口 的关系
继承: 空心三角形 + 实线；三角形指向父类
实现接口: 空心三角形 + 虚线；三角形指向接口
关联(association): 实线箭头；当一个类'知道'另一个类时
可以有基数
聚合(aggregation): 空心菱形 + 实线箭头；菱形指向群体，实线箭头指向个体
聚类表示一种弱的'拥有'关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分
可以有基数
E.g. 雁群 和 大雁
合成(composition): 实心菱形 + 实现箭头；菱形指向整体，实现箭头指向部分
合成表示一种强的'拥有'关系，体现了严格的部分和整体的关系，部分和整体的生命周期一样
合成关系的连线两端各有一个数字，称为基数，表示这一端的类可以有几个实例。
如果一个类可能有无数个实例，则可用'n'来表示。
E.g. 大雁 和 翅膀
依赖(Dependency): 虚线箭头；箭头指向被依赖对象
被依赖对象 一般作为 参数 或者 成员变量
模式总结
封装
多态
继承
组合
内聚性:
一个例程内部组成部分之间相互联系的紧密程度
耦合性:
一个例程和其他例程之间联系的紧密程度
软件开发的目标: 创建这样一个例程，内部完整，高内聚；而与其他例程之间的联系则小巧，直接，可见，灵活，松耦合。
面向对象的需求分析
这个东西叫什么
他从哪里来
他能做什么
Abstract Factory: 提供一个创建一系列或相关依赖对象的接口，而无需指定它们具体的类
AbstractFactory (ConcreteFactory1, ConcreteFactory2)
+ CreateProductA()
+ CreateProductB()
AbstractProductA (ProductA1, ProductA2)
AbstractProductB (ProductB1, ProductB2)
Client
- 产品抽象类个数对应于创建方法个数
- 具体工厂个数对应于每样抽象产品的具体产品个数
隐藏了这些类的实例是如何被创建和放在一起的，整个系统关于这些对象所知道的是由抽象类所定义的接口。这样，
创建型模式在创建了什么，谁创建它，它是怎么被创建这些方面提供了很大的灵活性
Builder: 将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示
Director
- builder
+ Construct()
Builder (ConcreteBuilder)
+ BuildPart()
+ GetResult()
Product
Client
将一个复杂对象的构建和它的表示分离，用同样的构建过程创建不同的产品
Factory Method: 定义一个用于创建对象的接口，让子类决定实例化哪一个类，工厂模式使一个类的实例化延迟到其子类
Factory (ConcreteFactory)
+ FactoryMethod()
Product (ConcreteProduct)
Client
创建对象时，负责创建的实体通常需要了解要创建的是哪个具体的对象，以及何时创建这个而非那个对象的规则。
如果希望遵循开放－封闭原则，依赖倒转原则和里氏代换原则，就不应该知道所用的是哪一个特选的对象。此时就需要'对象管理者'工厂类来负责此事。
Prototype: 用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象
Prototype (ConcretePrototype1, ConcretePrototype2)
+ Clone()
Client
- prototype
建立相应数目的原型并克隆它们通常比每次用合适的状态手工实例化该类更方便
Singleton: 保证一个类仅有一个实例，并提供一个访问它的全局访问点
Singleton
- instance : Singleton
- Singleton()
+ GetInstance() // 静态方法
创建型模式抽象了实例化的过程。它们帮助一个系统独立于如何创建，组合和表示它的那些对象。创建型模式都会将关于该系统使用哪些
具体的类的信息封装起来。允许客户用结构和功能差别很大的"产品"对象配置一个系统。配置可以是静态的，即在编译时指定，也可以是
动态的，就是运行时再指定。
通常设计应该是从工厂方法开始，当设计者发现需要更大的灵活性时，设计便会向其他创建型模式演化。
////// 结构型模式
Adapter: 将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作
Client
- target
Target (Adapter)
- adaptee
+ Request()
Adaptee
+ SpecificRequest()
为了解决两个已有接口之间不匹配的问题，我不需要考虑这些接口是怎么实现的，也不考虑它们各自可能会如何演化。
不需要修改任何一个类，就能使其协同工作。
Bridge: 将抽象部分与它的实现部分分离，使它们都可以独立的变化
Abstraction (RefinedAbstraction)
+ Operation()
Implementor (ConcreteImplementorA, ConcreteImplementorB)
+ OperationImp()
如果在继承体系中有多于一个方向的变化，解耦这些不同方向的变化，通过对象组合的方式，把两个角色之间的继承关系改为了
组合关系，从而使这两者可以应对各自独立的变化
Composite: 将对象组合成树形结构以表示'部分－整体'的层次结构，组合模式使得用户对单个对象和组合对象的使用具有一致性。
Component (Leaf, Composite)
+ Add (in c : Component)
+ Remove (in c : Component)
+ Display (in depth : int)
Client
Decorator: 动态地给一个对象添加一些额外的职责。就增加动能来说，装饰模式相比生成子类更加灵活
Component (ConcreteComponent, Decorator)
+ Operation()
ConcreteComponent
+ Operation()
Decorator (ConcreteDecoratorA, ConcreteDecoratorB)
+ Operation()
- component
ConcreteDecoratorA
+ Operation()
- addedState: state
ConcreteDecoratorB
+ Operation()
- AddedBehavior()
Facade: 为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用
Client
Facade
+ MethodA()
+ MethodB()
- subsystem_one
- subsystem_two
- subsystem_three
- subsystem_four
SubSystemOne:
+ MethodOne()
SubSystemTwo:
+ MethodTwo()
SubSystemThree:
+ MethodThree()
SubSystemFour:
+ MethodFour()
一个软件中的子系统间的通信和相互依赖关系达到最小，而具体办法就是引入一个外观对象，它为子系统间提供了一个单一而简单的屏障
分层设计就是外观模式的体现
Flyweight: 为运用共享技术有效地支持大量细粒度的对象
Client
- flyweight_factory
- concrete_flyweight
- unshared_concrete_flyweight
FlyweightFactory
+ GetFlyweight(in key : int) : Flyweight
- flyweights
Flyweight (ConcreteFlyweight, UnsharedConcreteFlyweight)
+ Operation(in extrinsic_state : int)
ConcreteFlyweight
+ Operation(in extrinsic_state : int)
UnsharedConcreteFlyweight
+ Operation(in extrinsic_state : int)
对象使得内存占用过多，而且如果都是大量重复的对象，可以考虑使用享元模式；将内部和外部特性分离
Proxy: 为其他对象提供一种代理以控制对这个对象的访问
Client
- subject
Subject (RealSubject, Proxy)
+ Request()
RealSubject
+ Request()
Proxy
- real_subject
+ Request()
代理 vs. 外观:
代理对象代表一个单一对象，而外观对象代表一个子系统；
代理的客户对象无法直接访问目标对象，由代理提供对单独的目标对象的访问控制，
而外观对象的客户对象可以直接访问子系统中的各个对象，但通常由外观对象提供对子系统各元件功能的简化的共同层次的调用接口。
代理 vs. 适配器:
代理对象 要与 原来对象 属于同一个父类；是原来对象的代表，其他需要与这个对象打交道的操作都是和这个代表交涉。
而适配器 与 原来对象 不属于同一个父类，而是提供需要的接口，并且以组合方式保含 原来的对象。
适配器 vs. 外观:
适配器是复用已有的接口，而外观是定义一个新的接口
适配器是为使两个已有的接口协同工作，而外观则是为现存系统提供一个更为方便的访问接口
适配器用来适配对象，而外观用来适配整个子系统 (粒度更大)
//// 行为型模式
Observer: 定义对象间的一种一对多的依赖关系，当一个对象的状态发生变化时，所有依赖于它的对象都得到通知并被自动更新
Subject (ConcreteSubject)
- observers
+ Attach(in : Observer)
+ Detach(in : Observer)
+ Notify()
ConcreteSubject
+ subjectState
Observer (ConcreteObserver)
+ Update()
ConcreteObserver
- subject
- observerState
+ Update()
目标和观察者不是紧密耦合，它们可以属于一个系统中得不同抽象层次，目标所知道得仅仅是它有一系列的观察者，每个观察者实现
observer的简单接口，观察者属于哪一类，目标是不知道的。
Template: 定义一个操作的算法骨架，而将一些步骤延迟到子类中，模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤
AbstractClass
+ TemplateMethod()
+ PrimaryOperation1()
+ PrimaryOperation2()
ConcreteClass
+ PrimaryOperation1()
+ PrimaryOperation2()
代码重复是编程中最常见，最糟糕的'坏味道'；模版方法模式由一个抽象类组成，抽象类定义了需要覆盖的hood method，由子类实现新方法
Command: 将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；可以对请求排队或记录请求日志，以及支持可撤销的操作
Client
- invoker
Invoker
- commands
Command <<Interface>> (ConcreteCommand)
+ Execute()
ConcreteCommand
- receiver : Receiver
+ Execute()
Receiver
接收者知道如何实施与执行一个请求相关的操作，任何类都可能成为一个接收者；不用统一Action接口
将一个接收者对象绑定于一个动作，调用接收者相应的操作，以实现Execute
所以ConcreteCommand需要知道接收者的细节
对于命令，执行操作需要一个统一的接口
将调用操作的对象与知道如何实现该操作的对象解耦；
调用者可以在不同时刻指定，排列合执行请求: 支持取消/重做的操作，记录整个事务的日志(支持事务)
State: 允许一个对象在其内部状态改变时改变它的行为，让对象看起来似乎修改了它的类。
Context: 维护一个ContextState子类的实例，这个实例定义当前的状态
- state
+ Request()
State (ConcreteStateA, ConcreteStateB, ConcreteStateC): 抽象状态类，定义一个接口以封装与Context的一个特定状态相关的行为
+ Handle()
ConcreteStateA: 具体状态，每一个子类实现一个与Context的一个状态相关的行为
+ Handle()
...
条件分支的大量应用情况下，状态模式提供了一个更好的办法来组织与特定状态相关的代码，决定状态转移的逻辑不在单块的if 或
switch中，而是分布在各个状态子类之间，由于所有与状态相关的代码都存在于某个状态子类中，所以通过定义新的子类可以很容易
地增加新的状态和转换。
Chain of Responsibility: 使多个对象都有机会处理请求，从而避免请求的发送者和接受者之间的耦合关系。
将这些对象连成一条链，并沿着这条链传递该请求，知道有一个对象处理它为止。
Client
- handler
Handler (ConcreteHandler1, ConcreteHandler2)
+ SetSuccessor(in successor : Handler)
+ HandleRequest(in request : int)
ConcreteHandler1: 具体处理者类，处理它所负责的请求，可访问它得后继者，如果可处理该请求，就处理之；否则就转发给后继者
- successor : Handler
+ HandleRequest(in request : int)
有多个对象可以处理一个请求，哪个对象处理该请求事先并不知道，要在运行时刻自动确定；此时，最好的办法就是让请求发送者和具体
处理者分离，让客户在不明确指定接收者的情况下，提交一个请求，然后由所有能处理这请求的对象连成一条链，并沿着这条链传递该请
求，直到有一个对象处理它为止。
Interpreter: 给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。
Client
Context: 包含解释器之外的一些全局信息
AbstractExpression (TerminalExpression, NonterminalExpression)
+ Interpret(in context : Context)
TerminalExpression
+ Interpret(in context : Context)
NonterminalExpression
+ Interpret(in context : Context)
如果一个特定类型的问题发生的频率足够高，那么就可以考虑将该问题的各个实例表述为一个简单语言的句子。也就是说，
通过构建一个解释器，该解释器解释这些句子来解决该问题。比如，正则表达式
Mediator: 用一个中介对象来封装一系列的对象交互。中介者使个对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
Mediator (ConcreteMediator)
ConcreteMediator: 知道所有具体同事类，并且接收和发送来自具体同事类的消息
Colleague (ConcreteColleague1, ConcreteColleague2): 定义同事对象到中介者对象的接口
- mediator : Mediator
ConcreteColleague1: 只了解中介者和自己的行为
...
将行为分布到各个对象中后，会导致对象间有许多连接，这无法很好应对改动。中介者封装了这些连接和交互，
使组中的对象不再相互显式引用。这些对象仅知道中介者，从而减少了相互连接数。满足最小知识原则，也就减少了耦合。
Visitor: 表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
Client
- visitors
- object_structure
ObjectStructure: 枚举它的元素，可以提供一个高层的接口以允许访问者，访问它的元素
- elements
Visitor (ConcreteVisitor1, ConcreteVisitor2)
+ VisitConcreteElementA(in : ConcreteElementA)
+ VisitConcreteElementB(in : ConcreteElementB)
ConcreteVisitor1
+ VisitConcreteElementA(in : ConcreteElementA)
+ VisitConcreteElementB(in : ConcreteElementB)
ConcreteVisitor2
+ VisitConcreteElementA(in : ConcreteElementA)
+ VisitConcreteElementB(in : ConcreteElementB)
Element (ConcreteElementA, ConcreteElementB)
+ Accept(in visitor : Visitor)
ConcreteElementA
+ Accept(in visitor : Visitor)
+ OperatorA()
ConcreteElementB
+ Accept(in visitor : Visitor)
+ OperatorB()
访问者增加具体的Element是困难的，但增加依赖于复杂对象结构的构件的操作就变的容易。仅需增加一个新的访问者即可在一个对象结构上定义新的操作。
Strategy: 定义一系列算法，把它们一个个封装起来，并且使它们可相互替换。本模式使得算法可以独立于使用它的客户而变化。
Context: 上下文，用一个ConcreteStrategy来配置维护对一个Strategy对象的引用
- strategy
+ ContextInterface() : 与使用strategy相关的接口
Strategy (ConcreteStrategyA, ConcreteStrategyB): 策略类，定义所有支持的算法的公共接口
+ AlgorithmInterface()
ConcreteStrategyA
+ AlgorithmInterface()
...
将算法封装在独立的策略Strategy类中使得你可以独立于Context类改变它，易于切换，易于理解，易于扩展。
Memento: 在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可以将该对象恢复到原先保存的状态。
Originator: 负责创建一个备忘录，用以记录当前时刻它的内部状态，并可使用备忘录恢复内部状态
+ State
+ SetMemento(in m : Memento)
+ CreateMemento()
Memento: 负责存储Originator对象的内部状态，并可防止Originator以外的其他对象访问备忘录
+ State
Caretaker: 负责保存好备忘录
- memento : Memento
避免暴露一些只应由对象A管理却必须存储在对象A之外的信息。备忘录模式把可能很复杂的对象A的内部信息对其它对象屏蔽起来，从而保持了封装边界。
Iterator: 提供一种方法顺序访问一个聚合对象中各个元素，而又不需暴露该对象的内部表示。
Aggregate (ConcreteAggregate)
+ CreateIterator() : Iterator
ConcreteAggregate
+ CreateIterator() : Iterator
Iterator (ConcreteIterator)
+ First()
+ Next()
+ IsDone()
+ CurrentItem()
ConcreteIterator
Client
将对列表的访问和历遍从列表对象中分离出来并放入一个迭代器对象中，迭代器类定义了一个访问该列表元素的接口。
迭代器对象负责跟踪当前元素，并知道哪些元素已经历遍过。
More
面向对象设计模式体现的就是抽象。类是对对象的抽象，抽象类是对类的抽象，接口是对行为的抽象。
MVC: 提高灵活性和复用性，集观察者，组合，策略一身
Model: 应用对象
View: 应用对象在屏幕上的表示
Controller: 定义用户界面对用户输入的响应方式
MVC是多模式的综合应用，算是一种架构模式