设计模式学习日记一(持续更新)

写在前面：小弟的设计模式学习笔记，目的是记录最近一段时间学习的过程，大婶们请勿喷~~~不胜感激！！！

GoF(Gang of Four)设计模式

常见的设计模式原则和SOLID设计原则

Fowler企业模式

一、 设计模式释义

设计模式是高层次的、抽象的解决方案模板。可以将这些模式视为解决方案的蓝本而不是解决方案本身。从中无法找到一种可以简单地运用到应用程序中的框架；相反，通常是通过重构自己的代码并将为题泛化来实现设计模式。

设计模式的起源

当前软件体系结构中比较流行的设计模式起源于程序员多年使用面向对象编程语言而积累的经验和知识。Design patterns: Elements of Reuable Object-Oriented Software(又被亲切的称为Design Patterns Bible，即“设计圣经”)一书收录了绝大多数最常见的模式。这本书是由Erich Gamma，Richard Helm，Ralph Johson和John Vlissides四人合著而成，而他们常被称为“四人组”（GoF）。

他们收录了23种设计模式并将他们归纳为3组。

  * 创建型模式：处理对象构造和引用。

  * 结构型模式：处理对象之间的关系一级它们之间如何进行交互以形成更大的复杂对象。

  * 行为型模式：处理对象之间的通信，特别是在责任和算法方面。

二、 设计原则

设计原则构成了设计模式赖以构建的基础。它们要比设计模式更加基础。通过遵循经过验证的设计原则，自己的代码基会变得更加灵活、更能够适应变化，而且可维护性更佳。

常见设计原则

1. 简约原则（KISS）

软件编程领域普遍存在的一个问题是需要把解决方案过度复杂化。KISS原则的目标就是让代码保持简洁但不要过于简陋，从而避免引入不必要的复杂度。

2. 不要重复自己（DRY）

DRY原则的目的是通过将公用的部分抽离出来放在一个单独的地方从而避免重复系统中的任何部分。这个原则不仅涉及代码而且包括系统中重复的任何逻辑。最终，系统中的任何一部分知识都应该只有一中表示形式。

3. 讲述而不要询问（Tell,Don't Ask）

该原则体现了封装以及将责任指派到正确的类这个思想。这个原则要求，应该告诉对象你希望它们执行什么动作，而不是询问有关该对象状态的问题然后由你自己决定希望执行什么动作。这个原则有助于匹配责任并避免类之间的紧密耦合。

4. 你不需要它（YAGNI）

YAGNI原则指的是只需要将应用程序必需的功能包含进来，而不要试图添加任何其他你认为可能需要的功能。测试驱动开发（DDD）就是一中坚持YAGNI原则的设计方法学。TDD的宗旨就是编写测试来验证系统的功能，然后只需要编写可让测试通过的代码即可。

5. 分离关注点（SoC）

SoC这一过程将软件分解为多项不同的功能，每项功能封装了可供其他类使用的唯一行为和数据。通常一个关注点代表类的一项功能或行为。将程序划分成若干个独立职责的做法显著提高了代码的重用程度、维护性和可测试性。

S.O.L.I.D 设计原则

1. 单一职责原则（SRP）

SRP原则与SoC原则保持高度一致。它要求每个对象只应该为一个元素而改变而且只有一个职责关注点。它使每个类均保持简洁，从而可以提升系统的可读性和可维护性。

2. 开放封闭原则（OCP）

OCP原则要求类对于扩展应该是开放的，而对于修改应该是封闭的，这样应该就能够在不改变类的内部行为的情况下添加新功能并扩展类。这个原则努力避免破坏已有的类以及其他依赖它的类，因为这会在应用程序中造成bug和错误的涟漪效应。

3. 里氏替换原则（LSP）

LSP原则指出应该能够使用任何继承类来代替父类并且让其行为方式保持不变。这个原则与OCP原则保持一致：它确保继承类不会影响父类的行为，换句话说，继承类必须可替代它们的基类。

4. 接口分离原则（ISP）

ISP原则关注的是将契约的方法划分成若干职责分组，并且为这些分组指派不同的接口，这样客户端就不需要实现一个庞大的接口和一堆它们并不使用的方法。这个原则背后的目的是：使用想同接口的类只需实现特定的一组方法，而不是实现一个庞大的单体方法接口。

5. 依赖倒置原则（DIP）

DIP原则的宗旨是将自己编写的类与具体的实现隔离开来，让这些类依赖于抽象类或接口。它提倡面向接口（而不是实现）编程，这确保代码不会与某种实现紧密耦合，从而提高了系统的灵活性。

6. 依赖注入（DI）和控制反转（IoC）原则

与DIP紧密相关的是DI原则和IoC原则。DI通过构造器、方法或属性来提供底层类或从属类。配合使用DI原则，这些从属类可以被反转为接口或抽象类，这样就可以形成一个具有较高的苛测试性和易于修改的松散耦合系统。

在IoC原则中，系统的控制流与过程式编程方法相比是反转的。这个原则的一个示例是IoC容器，它的作用是将服务注入到客户端代码，而不必让客户端代码指定具体的实现。在该示例中，控制反转指的是客户端获取服务的行为。

三、 Fowler的企业设计模式

领域逻辑模式

1. Transaction Script

Transaction Script模式按照线性的、过程式方法来组织业务逻辑。它将细颗粒度的业务用例映射为细颗粒度的方法。这种模式是最易于理解和运用的模式，它遵循的是过程式开发风格而不是面向对象的方法。通常，为每个业务事务创建一个单独的方法，并将它们组合起来放入某种静态管理程序或服务。通常说的三层就是这种模式，它的优势是易于理解，很快就可以让团队新成员上手而不需要具有该模式的预备知识，当新的需求出现时，很容易向该类中添加更多方法，而不用担心影响或破坏现有的功能。Transaction Script模式非常适合于那些逻辑中只包含很少或不包含可能增长的功能集合的小型应用程序，以及有不熟悉面向对象编程概念的初级开发者的团队。

当应用程序变大而且业务逻辑变得更复杂时，Transaction Script模式的问题就会暴露出来。扩展应用程序时，方法的数目也会变多，从而形成一个充斥着功能交叠的细颗粒度方法的无用API。尽管可以使用子方法来避免代码重复，如验证和业务规则，但在工作流中的复制不可避免，而且当应用程序规模变大时，代码基会变得笨重且不可维护。

2. Active Record

Active Record模式按照一种能够紧密匹配底层数据结构的方式来组织业务逻辑，即表中表示数据行的对象。

Active模式是一种流行的模式，尤其在底层数据库模型匹配业务模型时它特别有效。通常，数据库中的每张表都对应一个业务对象。业务对象也表示表中的一行，并且包含数据、行为以及持久化对象的工具，此外还有添加新实例和查找对象集合所需的方法。

在Active Record模式中，每个业务对象均负责自己的持久化和相关的业务逻辑。如果已经有数据库模型或者希望采用“数据优先”的方法来构建应用程序，这是一个可用的好模式。Active Record模式并非灵丹妙药。它擅长于处理底层数据模型能够很好映射到业务模型的情形，但是当出现不匹配时（有时候称为阻抗失配），该模式将很难应对。这是由于复杂系统的概念业务模型有时与数据模型不同所造成的。如果业务领域非常丰富，有着大量的复杂规则、逻辑和工作流，那么采用Domain Model模式将更加有利。

3. Domain Model

Domain Model模式是对现实领域对象的抽象。同时对数据和行为建模。对象之间可以存在与真实领域相匹配的复杂关系。可以将Domain Model视为表示正在处理的领域的概念层，事物和事物之间的关系都存在这个模型中。Domain Model与Active Record模式之间的主要差别在于，Domain Model中存在的业务实体并不知道如何持久化自己，而且没有必要在数据模型也业务模型之间建立一对一的映射关系。

 

《设计模式学习日记》后续内容提示：对象关系映射（UoW、Lazy Loading等），Web表示模式，基本模式、行为模式和结构模式，后面会上基于Active Record、Domain Model模式示例项目