这篇博文主要讲的是在Java面向对象设计中，我们应该遵循的六大原则。只有掌握了这几大原则，我们才能更好的理解设计模式。

Java面向对象设计的六大原则如下：

单一职责原则——SRP
开闭原则——OCP
里式替换原则——LSP
依赖倒置原则——DIP
接口隔离原则——ISP
迪米特原则——LOD

下面我们会通过具体的实例逐个讲解这几大原则。

一、单一职责原则（SRP）

单一职责原则定义接口或类和职责的关系是一一对应的，就一个类而言，应该有且仅有一个引起它变化的原因。也就是说一个类应该只负责一件事情。单一职责原则在日常开发中是经常用到的，以一个类举例，假如目前有2种动物，猫和狗，虽然它们之间是有相似的地方，但是我们在定义类的时候也会把它们区分成2个类；以接口举例，尽管List和Map都是用来存放数据的容器，但是它们的数据结构是不一样的，包含的方法也有区别，所以它们也被区分为2个接口。

1.1 遵循单一职责原则的好处

降低类或接口的复杂度。每个类或接口都只实现单一的职责，定义明确清晰，内部变量、方法等也容易理解；
代码可读性高。在类的定义和声明清晰的基础上，自然会带来较高的代码可读性；
代码可维护性高。代码可读性强，更容易理解，自然方便维护；类的职责单一，类之间耦合度低，所以更容易修改；
拓展性更好。有新的职责需要拓展，只需要新增成员或实现对应的接口即可。

1.2 实例分析

因为面向对象的编程是推崇面向接口编程的，所以我们对外暴露的方法也最好是以接口的形式定义，再由具体的类进行实现。下面就基于一个简单的场景来进行程序设计，满足单一职责原则。

扫描二维码关注公众号，回复： 15602322 查看本文章

我们知道苹果厂商早期生产Iphone4，是可以打电话、发短信的；后来发布了Iphone5，即可以打电话、发短信又可以支持指纹解锁；同时它还有一个产品是Ipad，可以指纹解锁，但是不能打电话、发短信。基于这个场景，我们来进行程序设计。

我们先定义几个接口，里面分别包含打电话、发短信、指纹解锁等方法，代码如下：

public interface CallInterface {
    public void call();
}
public interface MessageInterface {
    public void sendMessage();
}
public interface FingerPrintInterface {
    public void fingerPrint();
}

可以看到，这几个接口在定义的时候就根据功能划分设定了单一职责。然后我们再定义几个类，实现上面的几个接口，同样设定单一职责：

public class CallDevice implements CallInterface {
    @Override
    public void call() {
        System.out.println("我能打电话");
    }
}
public class MessageDevice implements MessageInterface {
    @Override
    public void sendMessage() {
        System.out.println("我能发短信");
    }
}
public class FingerPrintDevice implements FingerPrintInterface {
    @Override
    public void fingerPrint() {
        System.out.println("我能指纹解锁");
    }
}

CallDevice、MessageDevice、FingerPrintDevice相当于支持各种功能的零件，现在零件有了，我们需要生产设备了。我们首先生产Iphone4，它能打电话和发短信。打电话和发短信的零件已经有了，我们只需要装配上就可以。代码如下：

//在生产这台手机时我们就已经明确知道了它的功能(打电话和发短信)
public class Iphone4 implements CallInterface, MessageInterface {
    /**
     * 打电话的零件
     */
    private CallDevice callDevice = new CallDevice();
    /**
     * 发短信的零件
     */
    private MessageDevice messageDevice = new MessageDevice();

    @Override
    public void sendMessage() {
        messageDevice.sendMessage();
    }

    @Override
    public void call() {
        callDevice.call();
    }

    public static void main(String[] args) {
        Iphone4 iphone4 = new Iphone4();
        iphone4.call();
        iphone4.sendMessage();
    }

}

输出结果：

这样，一台Iphone4就生产出来了。同理，Iphone5、Ipad也可以简单装配出来。假如Iphone4出新款了，打电话逻辑和之前不一样了，那么只需要再定义一个零件类，它采用 “新技术” 实现CallInterface接口中的call方法，这样在Iphone4装配时，打电话模块采用新的零件就可以了。这就体现了单一职责的好处，它对于现有类的修改造成的影响有了约束。

1.3 扩展

通过上面的实例，我们可以对单一职责原则有一个更清晰的理解。其实在项目开发中，如果针对每个接口都提供一个实现类会导致类的数量很庞大，使用起来很不方便，所以，在上面实例的基础上，我们可以整合一些功能。

在下面的例子中，我们的接口依旧单一职责，但是接听和拨打电话的功能往往是不可分的，他们基本上是同时存在的。所以我们可以提供一个同时继承两个接口的实现类。代码如下：

public class CallAndMessageDevice implements CallInterface,MessageInterface{
    @Override
    public void sendMessage() {
        System.out.println("我即会发短信");
    }
    @Override
    public void call() {
        System.out.println("我又会打电话");
    }
}

1.4 注意点

对于单一职责原则，接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化；
单一职责原则的难点在于职责的划分，在不同情景和生产环境下我们对职责的细化是不同的。

二、开闭原则（OCP）

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

在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。开闭原则要求我们，当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。

2.1 遵循开闭原则的优势

通过扩展已有的软件系统，可以提供新的行为，以满足对软件的新需求，使变化中的软件系统有一定的适应性和灵活性；
已有的软件模块，特别是最重要的抽象层模块不能再修改，这就使变化中的软件系统有一定的稳定性和延续性；
这样的系统同时满足了可复用性与可维护性。

2.2 如何遵循开闭原则

抽象约束

通过接口或者抽象类约束扩展，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的public方法；
参数类型、引用对象尽量使用接口或者抽象类，而不是实现类；
抽象层尽量保持稳定，一旦确定即不允许修改。

元数据（metadata）控制模块行为

元数据就是用来描述环境和数据的数据，通俗地说就是配置参数，参数可以从文件中获得，也可以从数据库中获得。
Spring容器就是一个典型的元数据控制模块行为的例子，其中达到极致的就是控制反转（Inversion of Control）

制定项目章程

在团队中，建立项目章程是非常重要的，因为章程中指定了所有人员都必须遵守的约定，对项目来说，约定优于配置。

封装变化

对变化的封装包含两层含义：

将相同的变化封装到一个接口或者抽象类中；
将不同的变化封装到不同的接口或抽象类中，不应该有两个不同的变化出现在同一个接口或抽象类中。

2.3 实例分析

下面我们举例说明什么是开闭原则。以书店销售书籍为例，其类图如下：

IBook接口代码：

package com.moi.csdn;

public interface IBook {
    public String getName();
    public int getPrice();
    public String getAuthor();
}

NovelBook小说书籍类：

package com.moi.csdn;

public class NovelBook implements IBook{
    protected String name;
    protected int price;
    protected String author;
    public NovelBook(String name,int price,String author){
        this.name = name;
        this.price = price;
        this.author = author;
    }
    @Override
    public String getName(){
        return this.name;
    }
    @Override
    public int getPrice(){
        return this.price;
    }
    @Override
    public String getAuthor() {
        return this.author;
    }
}

Test类：

package com.moi.csdn;

public class Test {
    public static void main(String[] args) {
        IBook novel = new NovelBook("笑傲江湖",100,"金庸");
        System.out.println("书籍名字："+novel.getName()+"\n书籍作者："+novel.getAuthor()+"\n书籍价格："+novel.getPrice());
    }
}

输出结果：

以上是针对初期需求实现的代码，功能方面是没有问题的。但是目前有一个新需求，在书籍销售的过程中，我们经常因为各种原因，要打折来销售书籍，这是一个需求上的变化。我们应该如何设计并修改我们的代码呢？

我们有下面三个方法来应对新需求：

修改接口
在IBook接口中，增加一个方法getOffPrice(),专门用于进行打折处理，所有的实现类实现此方法。但是这样的一个修改方式，实现类NovelBook要修改，同时IBook接口应该是稳定且可靠，不应该经常发生改变，否则接口作为契约的作用就失去了。因此，此方案否定。
修改实现类
修改NovelBook类的方法，直接在getPrice()方法中实现打折处理。此方法是有问题的，因为我们在对应新需求的时候也要保证老需求功能的实现。当然我们也可以再增加getOffPrice()方法，这也是可以实现新需求，但是这里面就有两个读取价格的方法，因此，该方案也不是一个最优方案。
通过扩展实现类来解决
我们可以增加一个子类OffNovelBook,重写父类NovelBook的getPrice()方法。此方法修改少，对现有的代码没有影响，风险小，满足开闭原则。

修改后的类图：

代码：

package com.moi.csdn;

public class OffNovelBook extends NovelBook{
    public OffNovelBook(String name,int price,String author){
        super(name,price,author);
    }
    // 重写价格方法，当价格大于40，就打8析，其他价格就打9析
    public int getPrice(){
        if(this.price > 40){
            return (int) (this.price * 0.8);
        }else{
            return (int) (this.price * 0.9);
        }
    }
}

上面针对打折销售的功能开发完成了，我们只是增加了一个OffNovelBook类，我们修改的代码都是在上层模块，没有修改底层模块，代码改变量少，可以有效的防止风险的扩散。

2.4 总结扩展

通常情况下，我们可以把需求变化归纳为两种类型：

逻辑变化
只变化了一个逻辑，而不涉及其他模块。比如一个算法是a*b*c，现在需要修改为a+b+c，可以通过直接修改原有类中的方法的方式来完成，前提条件是所有依赖或关联类都按照相同的逻辑处理。
子模块变化
一个模块变化，会对其它的模块产生影响。特别是一个底层的模块变化必然引起其上层模块的变化，因此可以通过扩展实现该变化。

事实上，开闭原则无非就是想表达这样一层意思：用抽象构建框架，用实现扩展细节。当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。

三、里式替换原则（LSP）

里式替换原则严格的定义：如果对每一个类型为 T1的对象 o1，都有类型为 T2 的对象o2，使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。

里式替换原则通俗的定义：所有引用基类（父类）的地方必须能透明地使用其子类的对象。

里氏代换原则告诉我们，在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常。反过来则不成立，如果一个软件实体使用的是一个子类对象的话，那么它不一定能够使用基类对象。例如：我喜欢动物，那我一定喜欢狗，因为狗是动物的子类；但是我喜欢狗，不能据此断定我喜欢动物，因为我并不喜欢老鼠，虽然它也是动物。

所以说，里氏替换原则其实就是为“良好的继承”制定一些规范。

3.1 继承的优缺点

既然里氏替换原则是解决继承带来的问题，那么我们先总结一下使用继承的优缺点。

3.1.1 继承的优点

代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性；
提高代码的复用性；
子类可以形似父类，但又异于父类；
提高代码的可扩展性；
提高产品或项目的开放性。

3.1.2 继承的缺点

继承是侵入性的，只要继承就必须拥有父类的所有属性和方法；
降低代码的灵活性，子类必须拥有父类的属性和方法，让子类增加了约束；
增强了耦合性，当父类的常量、变量和方法被修改时，必须考虑子类的修改。

3.2 良好的继承规范

上面我们总结了继承的优缺点，也提出了里氏替换原则是为“良好的继承”制定一些规范，那么具体有哪些规范呢？

1、子类要完全实现父类的抽象方法，但尽量不要覆盖父类的非抽象方法。

这一点很容易理解，如果子类覆盖了父类的非抽象方法，当使用子类代替父类时，程序行为可能会有所改变。

举例：我们知道，计算器可以用来计算加减乘除。现在我们定义一个计算器类，里面实现非抽象的计算方法。

package com.moi.csdn;

public class Calculator {
    public int calculate(int num1, int num2) {
        return num1 + num2;
    }
}

然后我们再定义一个子类，继承Calculator类，它里面也实现计算方法，覆盖父类的方法。

package com.moi.csdn;

public class MiniCalculator extends Calculator{
    public int calculate(int num1, int num2) {
        return num1 - num2;
    }
}

可以看到，父类和子类都有calculate方法，父类是加法实现，子类是减法实现。我们再写一个Test类：

package com.moi.csdn;

public class Test {
    public static void main(String[] args) {
        Calculator calculator = new Calculator();
        System.out.println(calculator.calculate(10, 5));
        
        MiniCalculator calculator2 = new MiniCalculator();
        System.out.println(calculator2.calculate(10, 5));
    }
}

输出结果如下：

可以看到，由于子类MiniCalculator重写了父类Calculator的calculate方法，当子类MiniCalculator代替父类Calculator时，导致计算结果有误，也就是程序的行为发生了变化。所以对父类的非抽象方法，尽量不要覆盖重写。

2、子类中可以增加自己特有的方法。

子类一般都会有自己特有的属性或方法，这个无须赘述。

3、当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数要更抽象化。

举例说明，首先我们定义一个父类，Father类：

package com.moi.csdn;
import java.util.HashMap;
public class Father {
    public void doSomething(HashMap map){
        System.out.println("父类被执行");
    }
}

可以看到，Father类中doSomething方法中接收的是HashMap。下面定义子类Son：

package com.moi.csdn;
import java.util.Map;
public class Son extends Father{
    public void doSomething(Map map){
        System.out.println("子类被执行");
    }
}

最后是Test类：

package com.moi.csdn;
import java.util.HashMap;
import java.util.Map;
public class Test {
    public static void main(String[] args) {
        Father father = new Father();
        HashMap map = new HashMap();
        father.doSomething(map);

        Son son = new Son();
        Map map2 = null;
        son.doSomething(map2);
    }
}

执行结果如下：

可以看到，父类和子类分别执行。在这个例子中，子类方法的形参要比父类方法的形参更加抽象化。反之，则调用的都是父类方法，那么子类的方法重写就失去了意义。具体代码就不贴出来了，读者可以自行编码验证。

4、当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更具体化。

这个规范是必须要遵守的，否则会报编译错误。在上面的例子中我们给Father类doSomething方法加一个HashMap返回值，如果我们在Son类doSomething方法中返回Map，那么就会报错。如下：

3.3 实例分析

下面我们举例分析里式替换原则的用法。需求如下：

在Sunny软件公司开发的CRM系统中，客户(Customer)可以分为VIP客户(VIPCustomer)和普通客户(CommonCustomer)两类，系统需要提供一个发送Email的功能，无论是普通客户还是VIP客户，发送邮件的过程都是相同的，而且在本系统中还将增加新类型的客户。为了让系统具有更好的扩展性，同时减少代码重复，我们需要使用里氏代换原则进行设计开发。

在本实例中，可以定义一个抽象客户类Customer，同时将CommonCustomer和VIPCustomer类作为其子类，邮件发送类EmailSender类针对抽象客户类Customer编程，根据里氏代换原则，能够接受基类对象的地方必然能够接受子类对象，因此将EmailSender中的send()方法的参数类型改为Customer，如果需要增加新类型的客户，只需将其作为Customer类的子类即可。结构设计图如下：

开始编码。首先我们定义抽象类Customer：

package com.moi.csdn;
public abstract class Customer {
    public abstract String getName();
}

getName()方法用于区分发送Email的对象。

然后分别定义CommonCustomer和VIPCustomer继承Customer，并分别实现getName()方法：

package com.moi.csdn;
public class CommonCustomer extends Customer{
    @Override
    public String getName() {
        return "普通客户";
    }
}

package com.moi.csdn;
public class VIPCustomer extends Customer{
    @Override
    public String getName() {
        return "VIP客户";
    }
}

再定义EmailSender类，声明send方法，接收Customer参数用于发送邮件：

package com.moi.csdn;
public class EmailSender {
    public void send(Customer c){
        System.out.println("发送给:"+c.getName());
    }
}

最后是Test类及运行结果：

package com.moi.csdn;
public class Test {
    public static void main(String[] args) {
        EmailSender sender = new EmailSender();
        sender.send(new CommonCustomer());
        sender.send(new VIPCustomer());
    }
}

后续如果需要增加新类型的客户，只需将其作为Customer类的子类即可。

3.4 总结扩展

里氏代换原则是实现开闭原则的重要方式之一，由于使用基类对象的地方都可以使用子类对象，因此在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象。

在使用里氏代换原则时需要注意如下几个问题：

子类的所有方法必须在父类中声明，或子类必须实现父类中声明的所有方法。根据里氏代换原则，为了保证系统的扩展性，在程序中通常使用父类来进行定义，如果一个方法只存在子类中，在父类中不提供相应的声明，则无法在以父类定义的对象中使用该方法；
我们在运用里氏代换原则时，尽量把父类设计为抽象类或者接口，让子类继承父类或实现父接口，并实现在父类中声明的方法，运行时，子类对象替换父类对象，我们可以很方便地扩展系统的功能，同时无须修改原有子类的代码，增加新的功能可以通过增加一个新的子类来实现。里氏代换原则是开闭原则的具体实现手段之一；
Java语言中，在编译阶段，Java编译器会检查一个程序是否符合里氏代换原则，这是一个与实现无关的、纯语法意义上的检查，但Java编译器的检查是有局限的。

由于篇幅有限，本文先总结到这里，另外3大原则（依赖倒置原则、接口隔离原则、迪米特原则）将在后续博文中推出。

如有任何疑问，可关注公众号留言，工程师将尽快回答您的问题。公众号二维码：

Java面试题剖析（基础篇） | 第五篇: 深入理解Java面向对象设计的六大原则（上）