设计模式之类之间的关系和六大原则

1 类之间的关系

类与类之间的关系大概有6种，要看懂UML图，首先需要了解这几种关系。

1.1 继承关系

继承指的是一个类（称为子类，子接口）继承另外的一个类（成为父类，父接口）的功能，并可以增加它自己的新功能的能力。在UML类图设计中，继承用一条带空心三角箭头的实线表示，从子类指向父类，或者子接口指向父接口。

1.2 实现关系

实现指的是一个class类实现interface接口（可以是多个）的功能，实现是类与接口之间最常见的关系。在Java中此类关系是通过关键字implements明确标识，在设计时一般没有争议性。而在C++中并没有接口的关键字，这种关系一般是通过声明纯虚函数来实现。在UML类图设计中，实现是用一条带空心三角箭头的虚线表示，从类指向实现的接口。

1.3 依赖关系

简单的理解，依赖就是一个类A使用到了另一个类B，而这种使用关系是具有偶然性的、临时性的、非常弱的，但是B类的变化会影响到类A。比如某人要过河，需要借用一条船，此时人与船之间的关系就是依赖。表现在代码层面，为类B作为参数被类A在某个method方法中使用。在UML类图设计中，依赖关系用由类A指向类B的带箭头虚线表示。

1.4 关联关系

关联体现的是两个类之间语义级别的一种强依赖关系，比如我和我的朋友，这种关系比依赖更强、不存在依赖关系的偶然性、关系也不是临时性的，一般是长期性的，而且双方的关系一般是平等的。关联可以是单向、双向的。表现在代码层面，为被关联类B以类的属性形式出现在关联类A中，也可能是关联类A引用了一个类型为被关联类B的全局变量。在UML类图设计中，关联关系用由关联类A指向被关联类B的带箭头实线表示，在关联的两端可以标注关联双方的角色和多重性标记。

1.5 聚合关系

聚合关系是关联关系的一种特例，它体现的是整体与部分的关系，即has-a关系。此时整体与不放呢之间是可分离的，它们可以具有各自的生命周期，部分可以属于多个整体对象，也可以为多个整体对象共享。比如人群和单个人的关系，雁群与但只雁的关系。表现在代码层面，和关联关系是一致的，只能从语义级别来区分。在UML类图设计中，聚合关系以空心菱形加实线箭头表示。

1.6 组合关系

组合也是关联关系的一种特例，它体现的是一种contains-a的关系，这种关系比聚合关系更强，也成为强聚合。它同样体现在整体与部分的关系，但此时整体与部分是不可分的，整体的生命周期结束也就以为着部分的生命周期结束，比如人和人的大脑。表现在代码层面，和关联关系是一致的，只能从语义级别来区分。在UML类图设计中，组合关系以实心菱形加实线箭头表示。

1.7 总结

对于继承、实现这两种关系没多少疑问，它们体现的是一种类和类、或者类与接口间的纵向关系。其他的四种关系体现的是类和类或者类与接口间的引用、横向关系。相对来说比较难以区分。这四种关系都是语义级别的，所以从代码层面并不能完全区分各种关系，但总的来说，后几种关系所表现的强弱程度一次为：组合>聚合>关联>依赖。

2 六大原则

2.1 单一职责原则

单一职责原则指的是对于一个类而言，应该仅有一个引起它变化的原因。如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者一致这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意向不到的破坏。

同样的软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。其实要去判断是否应该分离出类来，也不难，那就是如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责，就应该考虑类的职责分离。

2.2 开放-封闭原则

开放-封闭原则，是说软件实体（类、模块、函数等等）应该可以扩展，但是不可以修改。这个原则其实有两个特征，一个是说对于扩展是开放的，另一个是说对于更改是封闭的。

但是无论模块是多么的‘封闭’，都会存在一些无法对之封闭的变化。既然不可能完全封闭，设计人员必须对于他设计的模块应该对哪种变化封闭做出选择。他必须先猜测出最有可能发生的变化种类，然后构造抽离来隔离那些变化。在我们最初编写代码时，假设变化不会发生。当变化发生时，我们就创建抽象来隔离以后发生的同类变化。面对需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码。

开发-封闭原则是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所生成的巨大好处，也就是可维护、可扩展、可服用、灵活性好。开发人员应该仅对程序中呈现出频繁变化的那些部分做出抽象，然而，对于应用程序中的每个部分都刻意地进行抽象同样不是一个好注意。拒绝不成熟的抽象和抽象本身一样重要。

2.3 依赖倒转原则

依赖倒转原则，简单地说就是抽象不应该依赖细节，细节应该依赖于抽象，就是要针对接口编程，不要对实现编程。依赖倒转原则：高层模块不应该依赖底层模块，两个都应该依赖抽象。抽象不应该依赖细节，细节应该依赖抽象。例如：主板、CPU、内存、硬盘都是在针对接口设计的，如果针对实现来设计，内存就要对应到具体的某个品牌的主板，那就会出现换内存需要把主板也换了的尴尬。这个原则很好理解，不过多赘述。

2.4 里氏代换原则

里氏代换原则是一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且它觉察不出父类对象和子类对象的区别。也就是说，在软件里面，把父类都替换成它的子类，程序的行为没有变化，简单地说，子类型必须能够替换掉它们的父类型。

2.5 接口隔离原则

使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。根据接口隔离原则，当一个接口太大时，我们需要将它分割成一些更小的接口，使用该接口的客户端仅需要知道与之相关的方法即可。每一个接口应该承担一种相对独立的角色，不干不该干的事，该干的事都要干。也就是说接口的定义要遵从单一职责原则。

2.6 迪米特法则

迪米特法则也叫最少知识原则。一个对象应该对其他对象保持最少的了解。如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。

迪米特法则首先强调的前提是在类的结构设计上，每一个类都应当尽量降低成员的访问权限，也就是说，一个类包装好自己的private状态，不需要让别额类知道的字段或行为就不要公开。迪米特法则其根本思想，是强调了类之间的松耦合。类之间的耦合越弱，越有利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及。

3 各种设计模式

常用的设计模式共有24种类，根据主要用途分为三类：创建型模式、结构型模式、行为型模式。也分为类模式和对象模式。如下图：

下面是各种设计模式的介绍：

简单工厂模式

策略模式

装饰模式

代理模式

工厂方法模式

原型模式

模板方法模式

外观模式

建造者模式

观察者模式

抽象工厂模式

状态模式

适配器模式

备忘录模式

组合模式

迭代器模式

单例模式

桥接模式

命令模式

责任链模式

中介者模式

享元模式

解释器模式

访问者模式