面向对象设计原则

设计模式是在特定环境下人们解决某类重复出现出现问题的一套成功或者有效的解决方案，为的是提高代码的可复用性。

面向对象的设计原则：

原则的目的：高内聚低耦合

1、单一职责原则：类的职责单一，对外只提供一种功能，而引起类变化的原因都应该只有一个

2、开闭原则：对扩展开放，对修改关闭。 增加功能是通过增加代码实现的而不是修改源代码   

3、里氏替换原则：任何抽象类（父类）出现的地方都可以用它的实现类（子类）进行替换，实际上就是虚拟机制，语言级别实现面向对象功能（实质上就是多态）

4、依赖倒转原则：依赖于接口（抽象）编程而不是依赖于实现（具体的类）编程，也就是针对接口编程

5、接口隔离原则：不应该强迫用户的程序依赖他们不需要的接口方法，一个接口应该只提供一种对外功能，不应该把所有的操作都封装到一个接口中去。

6、合成复用原则：继承会导致父类的任何变换都会影响到子类的行为。如果使用对象组合，就可以降低这种依赖关系。对于继承和组合，优先使用组合 。使用继承的唯一场景是需要向上转型或者需要多态的时候  

类的继承通常称为白箱复用，对象组合组合通常称为黑箱复用  。继承在某种程度上破坏了封装性，父类和子类耦合度极高。而对象组合只要求被组合的对象具有良好定义的接口，耦合度低    。

7、迪米特法则（又叫最少知识原则）：一个对象应对其他对象尽可能少的了解，从而降低各个对象之间的耦合，提高系统的可维护性。例如在一个程序中，各个模块之间相互调用时，通常会提供一个统一的接口来实现，这样其他模块不需要了解空一格模块的内部实现细节。如此，当一个模块内部的实现发生改变时，不会影响其他模块的使用（黑盒原理）

设计模式中的依赖：对于两个相对独立的对象，当一个对象负责构造另一个对象的实例，或者依赖另一个对象的服务时，这两个对象之间主要体现为依赖关系。依赖关系主要表现在：局部变量，方法参数以及对静态方法的调用

UML类图：

更正一下，上面的“这些数字被称之为技术”中的技术打错了，应该是“基数”

类与类之间的关系详解：

1、 [泛化]：表示类与类之间的继承关系，接口与接口之间的继承关系，或类对接口的实现关系。一般化的关系是从子类指向父类的，与继承或实现的方法相反。
[具体表现]：父类 父类实例＝new 子类()

2、依赖：对于两个相对独立的对象，当一个对象负责构造另一个对象的实例，或者依赖另一个对象的服务时，这两个对象之间主要体现为依赖关系。
[具体表现]：依赖关系表现在局部变量，方法的参数，以及对静态方法的调用

3、关联：对于两个相对独立的对象，当一个对象的实例与另一个对象的一些特定实例存在固定的对应关系时，这两个对象之间为关联关系。
[具体表现]：关联关系是使用实例变量来实现

4、聚合：当对象A被加入到对象B中，成为对象B的组成部分时，对象B和对象A之间为聚集关系。聚合是关联关系的一种，是较强的关联关系，强调的是整体与部分之间的关系。
[具体表现]：与关联关系一样，聚合关系也是通过实例变量来实现这样关系的。关联关系和聚合关系来语法上是没办法区分的，从语义上才能更好的区分两者的区别。
[关联与聚合的区别]
(1)关联关系所涉及的两个对象是处在同一个层次上的。比如人和自行车就是一种关联关系，而不是聚合关系，因为人不是由自行车组成的。
聚合关系涉及的两个对象处于不平等的层次上，一个代表整体，一个代表部分。比如电脑和它的显示器、键盘、主板以及内存就是聚集关系，因为主板是电脑的组成部分。
(2)对于具有聚集关系（尤其是强聚集关系）的两个对象，整体对象会制约它的组成对象的生命周期。部分类的对象不能单独存在，它的生命周期依赖于整体类的对象的生命周期，当整体消失，部分也就随之消失。比如张三的电脑被偷了，那么电脑的所有组件也不存在了，除非张三事先把一些电脑的组件（比如硬盘和内存）拆了下来。

5、组合：代表整体的对象负责代表部分对象的生命周期。公司不存在，部门也没有意义了。再例如：人和五脏六腑、四肢的关系。组合关系。