面向对象设计原则

面向对象设计的原则是面向对象思想的提炼，它比面向对象思想的核心要素更具可操作性，但与设计模式相比，却又更加的抽象，是设计精神要义的抽象概括。

面向对象设计的原则

1. 开放闭合原则 Open-Close Principle（OCP）
2. 单一职责原则 Single Responsibility Principle （SRP）
3. 里氏替换原则 Liskov Substituition Principle（LSP）
4. 依赖倒置原则 Dependence Inversion Principle（DIP）
5. 接口隔离原则 Interface Segregation Principle（ISP）
6. 组合/聚合复用原则 Composition/Aggregation ReusePrinciple（CARP）
7. 迪米特法则 Law of Demeter（LoD ）

前5条就是我们常说的面向对象设计五大基本原则。

1.开闭原则

对扩展开放，对修改闭合

面向对象设计中“可复用设计”的基石，是面向对象设计中最重要的原则之一，其它很多的设计原则都是实现开闭原则的一种手段

2.单一职责原则

一个类只负责做一件事情

3.里氏替换原则

子类可以扩展父类的功能，但不能改变父类原有的功能

• 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
• 子类中可以增加自己特有的方法。
• 当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。
• 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格.

任何基类可以出现的地方，子类一定可以出现。 LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏替换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏替换原则是对实现抽象化的具体步骤的规范。

4.依赖倒置原则

High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions。

• 高层次的模块不应该依赖于低层次的模块，他们都应该依赖于抽象。
• 抽象不应该依赖于具体实现，具体实现应该依赖于抽象。

依赖倒置原则（Dependence Inversion Principle）是程序要依赖于抽象接口，不要依赖于具体实现。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。

5.接口隔离原则

使用多个小的接口，而不使用一个大而全的接口

6.组合/聚合复用原则

类间关系尽量使用关联关系（组合、聚合），尽量少用继承关系。

组合：组合和聚合都是对象建模中关联（Association）关系的一种.聚合表示整体与部分的关系，表示“含有”，整体由部分组合而成，部分可以脱离整体作为一个独立的个体存在。组合则是一种更强的聚合，部分组成整体，而且不可分割，部分不能脱离整体而单独存在。在合成关系中，部分和整体的生命周期一样，组合的新的对象完全支配其组成部分，包括他们的创建和销毁。一个合成关系中成分对象是不能与另外一个合成关系共享

组合：A类的构造方法里创建B类的对象.也就是说，当A类的一个对象产生时，B类的对象随之产生;当A类的这个对象消亡时，它所包含的B类的对象也随之消亡。

聚合：A类的对象在创建时不会立即创建B类的对象，
而是等待一个外界的对象传给它

组合/聚合和继承是实现复用的两个基本途径。两者如何选择？
组合/聚合与继承实质是has-A与is-A的问题。

电脑has 内存、cpu、主板，这就是就是组合关系。Car（小轿车） is Vehicle（车辆），此时就可以使用继承。

//组合class Computer {    private ROM rom;    private CPU cpu;    private MainBoard mb;    Computer() {        rom = new ROM();        cpu = new CPU();        mb = new MainBoard();    }}class ROM {}class CPU {}class MainBoard {}

//继承abstract class Vehicle {    private String name;    public void setName(String name) {        this.name = name;    }    public String getName() {        return name;    }    //    abstract void run();}class Car extends Vehicle {    void run() {        System.out.println("Car is running");    }}

7.迪米特法则

迪米特法则（Law of Demeter）又叫作最少知道原则（Least Knowledge Principle 简写LKP），就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话。

迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。

迪米特法则不希望类之间建立直接的联系。因此，应用迪米特法则有可能造成的一个后果就是：系统中存在大量的中介类，这些类之所以存在完全是为了传递类之间的相互调用关系——这在一定程度上增加了系统的复杂度。

迪米特法则应用:
设计模式的门面模式（Facade）和中介模式（Mediator）