菜鸟学设计模式系列笔记之设计模式概论

模式是在某一个背景下的某一个问题的解决方案。

设计模式在很大程度上是为了解决软件的可复用性，而根据大量工程实践总结出来的软件体系结构，隐含包括了软件工程的面向对象思想：封装、继承、多态。

为什么需要设计模式：设计模式（Design Pattern ）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结，

使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码的可靠性。

设计模式一般有如下几个基本要素：模式名称、问题、目的、解决方案、效果、实例代码和相关的设计模式，关键因素包括以下四个方面：

（1）模式名称（Pattern name） （2）问题（Problem） （3）解决方案（Solution） （4）效果（Consequences）

面向对象方法中把一切都看成对象。对象是功能抽象和数据抽象的统一，对求解问题本身建模

面向对象的常用名词： 面向对象分析OOA、面向对象设计OOD 、面向对象编程OOP、面向对象编程 OOP、面向对象测试OOT 

面向对象的基本原则：（1）抽象Abstraction（2）封装Encapsulation（3）模块Modularity（4）层次化Hierarchy

面向对象的几个基本概念： 对象Object、类Class 、接口Interface、多态Polymorphism 、继承Inheritance、类（及对象）之间的关系

类（及对象）之间的关系：

（1）静态联系————关联association

关联是类与类之间的连接，使一个类知道另一个类的属性和方法。是类与类之间最常用的一类关系，它是一种结构化关系，用于表示一类对象和另一类对象之间有联系。

在UML类图中，用实线连接有关联对象所对应的类，在使用Java、C#和C++等编程语言表示关联关系时，通常将一个类的对象作为另一个类的属性。

包括三种关联关系：双向关联、单向关联、自关联

双向关联类图：

单向关联类图：

自关联类图：

（2）构成关系————聚合aggregation（整体-部分）

聚合关系是关联关系的一种，是强的关联关系，是整体和个体之间的关系。表示一个整体与部分的关系。

该整体类与成员类之间形成聚合关系，成员类是整体类的一部分。

如果不能确定一个关系是聚合关系，可以将它们设为关联关系。

在UML中聚合关系用带空心菱形的直线表示。

组合关系是关联关系中的一种，比聚合关系强，如果不能确定一个关系是不是组合关系，可将其设置为聚合关系，甚至关联关系。

也表示类之间整体与部分的关系，但是组合关系中的部分和整体具有相同的生命周期，一旦整体对象不存在，部分对象也将不存在，部分对象与整体对象之间具有同生共死的关系。

在UML中组合关系用带实心菱形的直线表示。

分类关系————泛化generalization（一般-特殊）

泛化关系（Generalization）也就是继承关系，泛化关系用于描述父类和子类之间的关系，父类又称作基类或超类，子类又称作派生类。

在UML中泛化关系用带空心的三角形的直线来表示

JAVA语言中使用extends关键字、在C++/C#使用冒号“：”来实现。

接口与实现关系，接口之间也可以有与类之间关系类似的继承关系与依赖关系，但是接口与类之间还存在一种实现关系（Realization），在这种关系中，类实现了借口，类中的操作实现了接口中所申明的操作。在UML中，类与接口之间的实现关系用带空心三角形的虚线来表示。

使用关系————依赖Dependency（行为依赖）

依赖关系是一种使用关系，特定事物的改变有可能会影响到使用该事物的其他事物，在需要表示一个事物使用另一个事物时的使用依赖关系。

大多数情况，依赖关系体现在某个类的方法使用另一个类的对象作为参数。

在UML中，依赖关系用带箭头的虚线表示

一个好的软件系统需要包含三个特性：扩展性（Extensibility）、灵活性（Flexibility）、可插入性（Pluggability）

软件设计的七大原则：

（1）单一职责原则（SRP） 

就一个类而言，应该只有一个导致其变化的原因。

类的职责主要包括两个方面的：数据职责和行为职责，数据职责通过其属性来体现，而行为职责通过其方法来表现。

单一职责原则 是实现高内聚、低耦合的指导方针。

对应的设计模式：Facade 、Proxy

（2）开-闭原则（OCP）

设计一个模块时，应当使该模块在不被修改的前提下被扩展，即可在不必修改源代码的情况下改变该模块的的行为。

抽象化是开闭原则的关键，开闭原则还可以通过一个更加具体的“对可变性封装原则”来描述，对可变性封装原则要求找到系统的可变因素将其封装起来。

一种可变性不应该散落在代码的很多角落里，而应该被封装在一个对象里。（继承可被看作封装变化的方法）

一种可变性补英语另一种可变性混在一起。（继承的层次不应太多了）

对应的设计模式：Strategy 、Simple Factory 、Factory Method、Abstract Factory、Builder、Bridge、Facade、Mediator、

(3)Liskov替换原则（LSP）

一个软件实体如果使用的是一个基类的话，一定适用与其子类，而且根本不能察觉出基类对象和子类对象的去区别

即：子类型（Subtype）必须能够替换他们的基类型(Basetype).

在软件设计中如果能够使用基类对象，那么一定能够使用其子类对象。

在程序中尽量使用基类类型来对对象进行定义，而在运行时在确定其子类类型，用子类对象来替换父类对象。

如果有一个由继承关系形成的等级结构的话，那么在等级结构的树图上面的所有树叶节点都应该是具体类，

而所有的树枝节点都应该是抽象类或接口。

对应的设计模式：Strategy 、Composite、Proxy

（4）依赖倒置原则（DIP）

高层模块不应该依赖低层模块，他们不应该依赖抽象，抽象不应该依赖于细节，细节应该依赖于抽象。

要针对接口编程，不要针对实现编程

代码要依赖于抽象的类，而不要依赖与具体的类；要针对接口或抽象类编程，而不是针对具体类编程

依赖倒置原则的常用实现方式之一是在代码中使用抽象类，而将具体类放在配置文件中

对应的设计模式：Factory Method 、Prototype、Iterator

（5）接口隔离原则（ISP）

使用多个专门的接口比使用单一的总接口要好

一个类对另外一个另类的依赖性应建立在最小的接口上

一个接口就只代表一个角色，每个角色都有它特定的一个接口，接口仅仅提供客户端需要的行为，及所需要的方法，客服端不需要的行为则隐藏起来。

相应的设计模式：Mmento 、Iterator

（6）组合/聚合复用原则（CARP）

要尽量使用组合/聚合，尽量不是要使用继承

在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分，新对象通过向这些对象的委派达到复用已有功能的目的。

只有以下的Coad条件全部被满足时，才应当使用继承关系：

1.子类是超类的一个特殊种类，而不是超类的一个角色。

2.永远不会出现需要将子类换成另外一个类的子类的情况。

3.子类具有扩展超类的责任，而不是具有置换掉或注销掉超类的责任。

4.只有在分类学角度上有意义时，才可以使用继承。不要从工具类继承。

优先使用对象组合，而非（类）继承

（7）迪米特法则（LoD）

一个对象应该对其他对象有尽可能少的了解

狭义的迪米特法则（LoD）

1.如果两个类不必彼此直接通信，那么这两个类就不应该直接发生相互作用

2.如果其中一个类需要调用另外一个类的某一个方法的话，可以通过第三者转发这个调用

广义的迪米特法则（LoD）

1.在类的划分上，创建弱耦合的类

2.类的结构设计上，每个类应降低成员的访问权限；

3.类的设计上，只要有可能，设计成不变类

4.对其他类的引用上，对其他对象的引用应该降到最低

相应的设计模式：Facade、Mediator

七大设计原则小结：

GOF的设计模式主要包括：二十三种设计模式总结