设计模式的基本原则 + 类与类之间的关系

设计模式的基本原则：
1)开放封闭原则(OCP, Open For Extension, Closed For Modification Principle)
类的改动是通过增加代码进行的，而不是修改源代码。
2)单一职责原则(SRP, Single Responsibility Principle)
类的职责要单一，对外只提供一种功能，而引起类变化的原因都应该只有一个。
3)依赖倒置原则(DIP, Dependence Inversion Principle)
依赖于抽象(接口), 不要依赖具体的实现(类)，也就是针对接口编程。
4)接口隔离原则(ISP, Interface Segegation Principle)
不应该强迫客户的程序依赖他们不需要的接口方法。一个接口应该只提供一种对外功能，不应该把所有操作都封装到一个接口中去。
5)里氏替换原则(LSP, Liskov Substitution Principle)
任何抽象类出现的地方都可以用他的实现类进行替换。实际就是虚拟机制，语言级别实现面向对象功能。
6)优先使用组合而不是继承原则(CARP, Composite / Aggregate Reuse Principle)
如果使用继承，会导致父类的任何变换都可能影响到子类的行为。
如果使用对象组合，就降低了这种依赖关系。
7) 迪米特法则(LOD, Law of Demeter)
一个对象应当对其他对象尽可能少的了解，从而降低各个对象之间的耦合，提高系统的可维护性。例如在一个程序中，各个模块之间
相互调用时，通常会提供一个统一的接口来实现。这样其他模块不需要了解另外一个模块的内部实现细节，这样当一个模块内部的实
现发生改变时，不会影响其他模块的使用。
类与类之间的关系：
1 泛化（应该也叫继承吧）(Generalization)
表示类与类之间的继承关系，接口与接口之间的继承关系，或类对接口的实现关系。一般画的关系是从子类指向父类的。
2 依赖(Dependency)（对象注入技术--将对象传递给含有对象指针参数的函数，那么此函数遍可以控制此对象了）
对象之间的临时关系，临时性体现在不超越方法的周期。在方法使用到的，如参数类，就一定是依赖关系。
3 关联(Association)

   关联是通过实例来完成的，当一个实例化的类作为了另一个类的成员变脸。在此类中又调用了实例化类的成员函数，那么这个

成员函数的类和这个类就是关联关系

4 聚合（Aggregation）
   表示两个对象之间是整体和部分的弱关系，部分的生命周期可以超越整体。如电脑和鼠标、
5 组合（combination）
  表示两个对象之间是整体和部分的 强 关系，部分的生命周期不能超越整体，在我看来就是将另一个类作为成员变量，但是这个成员的变量的位置方式放在了构造函数里面，所以体现出了他很强吧，我直接构造了。

总的来说，后几种关系所表现的强弱程度依次为：组合>聚合>关联>依赖。

参考来源：传智播客--王保明