六大设计原则（简述）

单一职责原则

单一职责原则（Single Responsibility Principle，SRP）：要求一个接口或类有且仅有一个原因引起变化，也就是一个接口或类只有一个职责，它就负责一件事情。

好处：

• 类的复杂性降低，实现什么职责都有清晰明确的定义；
• 可读性提高。
• 可维护性提高。
• 变更引起的风险降低。如果一个接口修改只对相应的实现类有影响，这对系统的扩展性、维护性都有非常大的帮助。

单一职责适用于接口、类，同时也适用于方法，一个方法尽可能只做一件事情。

对于实际编程中的单一职责原则，接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。

---

里氏替换原则

里氏替换原则（Liskov Substitution Principle，LSP）：只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常。

定义4层含义：

（1）子类必须完全实现父类的方法

注意：在类中调用其他类时务必要使用父类或接口，如果不能使用父类或接口，则说明类的设计已经违背了LSP原则。

如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发生“畸变”，则建议断开父子继承关系，采用依赖、聚集、组合等关系代替继承。

（2）子类可以有自己的个性

在子类出现的地方，父类未必就可以胜任。

（3）覆盖或实现父类的方法时输入参数可以被放大

public class Father {
    public Collection doSomething(HashMap map){
        System.out.println("父类被执行...");
        return map.values();
    }
} 

public class Son extends Father {
    //放大输入参数类型
    public Collection doSomething(Map map){
        System.out.println("子类被执行...");
        return map.values();
    }
}

（4）覆写或实现父类的方法时输出结果可以被缩小

父类的一个方法的返回值是一个类型T，子类的相同方法（重载或覆写）的返回值为S，那么里氏替换原则就要求S必须小于等于T，也就是说，要么S和T是同一个类型，要么S是T的子类。

---

依赖倒置原则

依赖倒置原则（Dependence Inversion Principle,DIP）：通过抽象（接口或抽象类）使各个类或模块的实现彼此独立，实现模块间的松耦合。

使用依赖倒置，需要遵循几个规则：

• （1）每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备
• （2）变量的表面类型尽量是接口或者是抽象类
• （3）任何类都不应该从具体类派生
• （4）尽量不要覆写基类的方法，覆写了抽象方法，对依赖的稳定性会产生一定的影响。
• （5）结合里氏替换原则使用

“倒置”：我们根据系统设计的需要产生了抽象间的依赖，代替了人们传统思维中的事物间的依赖，“倒置”就是从这里产生的。

---

接口隔离原则

这里的接口分为两种：

• （1）实例接口（Object Interface）：定义一个Person类，然后使用 Person zhangSan=new Person() 产生一个实例，这个实例要遵从的标准就是Person这个类，Person类就是zhangSan的接口。
• （2）类接口（Class Interface）：interface关键字定义的接口。

接口隔离原则：建立单一接口，接口尽量细化，接口中的方法尽量少，不要过于臃肿庞大。

• （1）接口要尽量小。根据接口隔离原则拆分接口时，首先必须满足单一职责原则。
• （2）接口要高内聚。提高接口、类、模块的处理能力，减少对外的交互。具体到接口隔离原则就是，要求在接口中尽量少公布public方法，接口是对外的承诺，承诺越少对系统的开发越有利，变更的风险也就越 少，同时也有利于降低成本。
• （3）定制服务。单独为一个个体提供优良的服务。
• （4）接口设计是有限度的。接口的设计粒度越小，系统越灵活。但是，灵活的同时也带来了结构 的复杂化，开发难度增加，可维护性降低。因此，要适度。

---

迪米特法则

迪米特法则（Law of Demeter，LoD）也称为最少知识原则（Least Knowledge Principle，LKP）：一个对象应该对其他对象有最少的了解。即类间解耦，弱耦合。

包含4层含义：

• （1）只和朋友交流。两个对象之间的耦合（组合、聚合、依赖）就成为朋友关系。出现在成员变量、方法的输入输出参数中的类称为成员朋友类。
• （2）朋友间也是有距离的。迪米特法则要求类“羞涩”一点，尽量不要对外公布太多的public方法和非静态的public变量，尽量内敛，多使用private、package-private、protected等访问权限。
• （3）是自己的就是自己的。如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，那就放置在本类中。
• （4）谨慎使用Serializable。在一个项目中使用RMI（Remote Method Invocation，远程方法调用）方式传递一个VO（Value Object，值对象），这个对象就必须实现Serializable接口（仅仅是一个标志性接口，不需要实现具体的方法），也就是把需要网络传输的对象进行序列化，否则就会出现NotSerializableException异常。突然有一天，客户端的VO修改了一个属性的访问权限，从private变更为public，访问权限扩大了，如果服务器上没有做出相应的变更，就会报序列化失败。

在实际应用中，如果一个类跳转两次以上才能访问到另一个类，就需要进行重构了。

---

开闭原则

开闭原则：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。

对扩展开放，对修改关闭，并不意味着不做任何修改，低层模块的变更，必然要有高层模块进行耦合，否则就是一个孤立无意义的代码片段。

注意：一般程序将价格定义为int类型并不是错误，在非金融类项目中对货币处理时，一般取2位精度，通常的设计方法是在运算过程中扩大100倍，在需要展示时再缩小100倍，减少精度带来的误差。