目录
1、 对象间的关系
类和类的关系
1、继承（泛化 generalization ）
2、实现（realization）
3、依赖（dependency）
4、关联（association）
5、聚合（aggregation）
6、组合（composition）
强调 ：聚合、组合是关联的特殊形式，从语义上区分。总体来说，关系强弱程度上依赖<关联<聚合<组合
1.1、依赖关系
定义：可以简单的理解，类A依赖于类B就是类A使用到了类B，类B的变化会影响到类A
这种关系一般是偶然性的、临时性的、非常弱的，依赖关系总是单向的。
表现在代码层面，类B作为参数或局部变量被类A在某个method方法中使用，此时类A依赖于类B
UML表示
类A依赖于类B，用由类A指向类B的带箭头虚线表示。
1.2、关联关系
关联是类和类之间的一种强依赖关系，这种关系一般具有长期性。关联可以是单向、双向的
关联可分为一对一关联、一对多关联、多对多关联
表现在代码层面：被关联类B以类的属性形式出现在关联类A中，关联类A引用了一个类型为被关联类B的全局变量。
UML表示：用带箭头实线表示，箭头指向被关联类；若是双向关联，实线两端可不带箭头。
1.3、聚合关系
定义：关联关系的一种特例，体现的是整体与部分的关系，即has-a的关系，整体与部分之间可分离，具有各自的生命周期
比如计算机与CPU、公司与员工、班级和学生、比如航母编队包括航空母舰、驱护舰艇、舰载飞机等
表现在代码层面，和关联关系是一致的，只能从语义级别来区分
UML表示：以空心菱形加实线箭头表示。
1.4、组合关系
定义：也是关联关系的一种特例，体现的是一种contains-a的关系, 比聚合更强，也称为强聚合，体现整体与部分间的关系，但整体与部分具有相同生命周期，一旦整体对象不存在，部门对象也将不存在。比如人和人的四肢
表现在代码层面，和关联关系是一致的，只能从语义级别来区分
UML表示：以实心菱形加实线箭头表示。
1.5、继承关系
1.6、实现关系
2、面向对象的设计原则
2.0、面向对象设计原则概述
2.1、单一职责
单一职责原则(Single Responsibility Principle, SRP)定义如下：：系统中的每一个类都应该只有一个职责，而所有类所关注的就是自身职责的完成
另一种定义方式如下：就一个类而言，应该仅有一个引起它变化的原因。如果能想到多个原因去改变一个类，这个类就具有多个职责。并不是单一功能原则，并不是每个类只能有一个方法，而是单一“变化的原因”原则。
一个类（或者大到模块，小到方法）承担的职责越多，它被复用的可能性越小。而且如果一个类承担的职责过多，就相当于将这些职责耦合在一起，当其中一个职责变化时，可能会影响其他职责的运作。
类的职责主要包括两个方面：数据职责和行为职责，数据职责通过其属性来体现，而行为职责通过其方法来体现。
单一职责原则是实现高内聚、低耦合的指导方针，在很多代码重构手法中都能找到它的存在，它是最简单但又最难运用的原则，需要设计人员发现类的不同职责并将其分离，而发现类的多重职责需要设计人员具有较强的分析设计能力和相关重构经验。
2.2、开闭原则
开闭原则(Open-Closed Principle, OCP)定义如下：一个软件实体应当对扩展开放，对修改关闭。也就是说在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展，即实现在不修改源代码的情况下改变这个模块的行为。
开闭原则由Bertrand Meyer于1988年提出，它是面向对象设计中最重要的原则之一。
在开闭原则的定义中，软件实体可以指一个软件模块、一个由多个类组成的局部结构或一个独立的类。
实现：实现开闭原则的关键是抽象，定义一个抽象层，只规定功能而不提供实现，实现通过定义具体类来完成，当需求变化时，不是通过修改抽象层来完成，而是通过定义抽象层的新实现完成，即通过扩展来完成。通过抽象类及接口，规定了具体类的特征作为抽象层，相对稳定，不需修改，从而满足“对修改关闭”。从抽象类导出的具体类可以改变系统的行为，从而满足“对扩展开放”
2.3、里氏替换原则
里氏代换原则(Liskov Substitution Principle, LSP)有两种定义方式。
第一种定义方式相对严格，其定义如下：如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有变化，那么类型S是类型T的子类型。
第二种更容易理解的定义方式如下：所有引用基类（父类）的地方必须能透明地使用其子类的对象。而不影响功能。
里氏代换原则可以通俗表述为：在软件中如果能够使用基类对象，那么一定能够使用其子类对象。把基类都替换成它的子类，程序将不会产生任何错误和异常，反过来则不成立，如果一个软件实体使用的是一个子类的话，那么它不一定能够使用基类。
里氏代换原则是实现开闭原则的重要方式之一，由于使用基类对象的地方都可以使用子类对象，因此在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象。
里氏代换原则是对开闭原则的扩展，采用开闭原则必然用到抽象和多态，而这离不开继承。里氏代换原则就是对如何良好继承提出了衡量依据。
修改类的设计
2.4、依赖倒转原则
依赖倒转原则(Dependence Inversion Principle, DIP)的定义如下：
高层模块不应该依赖低层模块，它们都应该依赖抽象。抽象不应该依赖于细节，细节应该依赖于抽象。另一种表述为：要针对接口编程，不要针对实现编程。
依赖倒转原则分析
简单来说，依赖倒转原则就是指：代码要依赖于抽象的类，而不要依赖于具体的类；要针对接口或抽象类编程，而不是针对具体类编程。
实现开闭原则的关键是抽象化，并且从抽象化导出具体化实现，如果说开闭原则是面向对象设计的目标的话，那么依赖倒转原则就是面向对象设计的主要手段。
2.5、接口隔离
接口隔离原则(Interface Segregation Principle, ISP)的定义如下：
客户端不应该依赖那些它不需要的接口。注意，在该定义中的接口指的是所定义的方法。
另一种定义方法如下：一旦一个接口太大，则需要将它分割成一些更细小的接口，使用该接口的客户端仅需知道与之相关的方法即可。
接口隔离原则是指使用多个专门的接口，而不使用单一的总接口。每一个接口应该承担一种相对独立的角色，不多不少，不干不该干的事，该干的事都要干。
(1) 一个接口就只代表一个角色，每个角色都有它特定的一个接口，此时这个原则可以叫做“角色隔离原则”。
(2) 接口仅仅提供客户端需要的行为，即所需的方法，客户端不需要的行为则隐藏起来，应当为客户端提供尽可能小的单独的接口，而不要提供大的总接口。
使用接口隔离原则拆分接口时，首先必须满足单一职责原则，将一组相关的操作定义在一个接口中，且在满足高内聚的前提下，接口中的方法越少越好。
可以在进行系统设计时采用定制服务的方式，即为不同的客户端提供宽窄不同的接口，只提供用户需要的行为，而隐藏用户不需要的行为。
改造
2.6、合成复用原则
合成复用原则(Composite Reuse Principle, CRP)又称为组合/聚合复用原则(Composition/ Aggregate Reuse Principle, CARP)，其定义如下：尽量使用对象组合，而不是继承来达到复用的目的。
合成复用原则就是指在一个新的对象里通过关联关系（包括组合关系和聚合关系）来使用一些已有的对象，使之成为新对象的一部分；新对象通过委派调用已有对象的方法达到复用其已有功能的目的。简言之：要尽量使用组合/聚合关系，少用继承。
2.7、迪米特法则
迪米特法则(Law of Demeter, LoD)又称为最少知道原则(Least Knowledge Principle, LKP)，它有多种定义方法，其中几种典型定义如下：
不要和“陌生人”说话。
只与你的直接朋友通信。
每一个软件单位对其他的单位都只有最少的知道，而且局限于那些与本单位密切相关的软件单位。
简单来说，迪米特法则就是指一个软件实体应当尽可能少的与其他实体发生相互作用。这样，当一个模块修改时，就会尽量少的影响其他的模块，扩展会相对容易，这是对软件实体之间通信的限制，它要求限制软件实体之间通信的宽度和深度。
