面向对象七大设计原则_实体类的设计理念

1:开闭原则(Open for Extension，Closed for Modification)    就是对程序修改关闭，对程序扩展开放。就是在不改变一个程序源码的情况下 改变程序的行为。如何做到既不修改，又可以扩展？    解决问题的关键在于抽象化：在Java语言里，可以给出一个或多个抽象Java类或Java接口，规定出所有的具体类必须提供的方法特征作为系统设计的抽象层。这个抽象层预见了所有的可能扩展，因此，在任何扩展情况下都不会改变。这就使得系统的抽象层不需要修改，从而满足了—对修改关闭。     同时，由于从抽象层导出一个或多个新的具体类可以改变系统的行为，因此系统的设计对扩展是开放的。解决问题的关键在于抽象化：在Java语言里，可以给出一个或多个抽象Java类或Java接口，规定出所有的具体类必须提供的方法特征作为系统设计的抽象层。这个抽象层预见了所有的可能扩展，因此，在任何扩展情况下都不会改变。这就使得系统的抽象层不需要修改，从而满足了—对修改关闭。   同时，由于从抽象层导出一个或多个新的具体类可以改变系统的行为，因此系统的设计对扩展是开放的。

2：依赖倒转原则(Dependence Inversion Principle )     就是依赖于抽象，不要依赖于实体类。   最简单的例子：比如一个方法需要一个 动物类型的参数来运行 那么如果我们在形参那里写的只具体的某一种动物 那么这个方法就只能为这一种动物服务。如果我们在形参上写的是动物这个类 那么我们就能为动物的所有子类提供服务了 这就是依赖于抽象而不是依赖于具体。   

问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。

问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。

解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B和类C发生联系，则会大大降低修改类A的几率。

核心思想：面向接口编程。含有下面3点：

1. 低层模块尽量都要有抽象类或接口，或者两者都有

2. 变量的声明类型尽量使抽象类或接口

3. 用继承时遵循里氏替换原则

 3. 合成/聚合复用原则     要尽量使用合成/聚合，而不是继承关系达到复用的目的。如果使用继承、子类无条件的继承父类的全部方法与属性、这其中有些方法或者属性 子类可能不需要、那么就会造成代码污染。而且我们都知道继承只能够单继承、不可以多继承。如果一个类需要多个方法 但是没有一个类拥有全部的方法  那么靠继承就无法完成.所以是用聚合复用原则还解决了java只能单继承的缺陷。

4.里氏替换原则(Liskov Substitution Principle) 定义1：如果对每一个类型为T1的对象o1，都有类型为T2的对象o2，使得以T1定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型T2是类型T1的子类型。 定义2：所有引用基类的地方必须能透明地使用其子类的对象。 通俗来讲：子类可以扩展父类的功能，但不能改变父类原有的功能。是OCP的扩展。它包含以下四层含义： 1. 子类可以实现父类的抽象，但不能覆盖父类的非抽象方法 2. 子类中可以增加自己特有的方法 3. 当子类的方法重写父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入更宽松 4. 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类的更严格

5.迪米特原则(Law Of Demeter)  一个对象应该对其他对象尽可能少地了解，意思就是降低各个对象之间的耦合，提高系统的可维护性  在模块之间，应该只通过接口通信，而不理会模块的内部工作原理，它可以使各个模块耦合度降到最低，促进软件的复用

6.接口隔离原则(Interface Segregation Principle)   一个接口不需要提供太多的行为，应该只提供一种对外的功能（这里的接口不仅仅是通过interface关键字定义的接口，还包括对象接口，如Phone phone = new Phone()）  接口分离原则要求在一个模块中应该只依赖它需要的接口，这就要求设计接口的时候应该尽量细化  接口分离原则与单一职责原则有些类似，不同之处在于：单一职责原则要求的是类和接口职责单一，注重的是职责，是业务逻辑上的划分；而接口分离原则要求的是接口的方法尽量少，针对一个模块尽量有用