本文正在参加「金石计划」

一、设计模式七大原则

1.1、设计模式的目的

编写软件过程中，程序员面临着来自耦合性，内聚性以及可维护性，可扩展性，重用性，灵活性等多方面的挑战，设计模式是为了让程序(软件)，，使用设计模式有以下的好处：

代码重用性高，即相同功能的代码，不用多次编写。
可读性强，具有编程规范性, 便于其他程序员的阅读和理解。
可扩展性高，即当需要增加新的功能时，非常的方便。
可靠性高，即当我们增加新的功能后，对原来的功能没有影响。
使程序呈现高内聚，低耦合的特性。

1.2、设计模式七大原则

设计模式原则，其实就是程序员在编程时，应当遵守的原则，也是各种设计模式的基础，即设计模式为什么这样设计的依据。常见的设计模式的七大原则有：

单一职责原则
接口隔离原则
依赖倒转(倒置)原则
里氏替换原则
开闭原则
迪米特法则
合成复用原则

1.2.1、单一职责原则

1.2.1.1、基本介绍

对类来说的，即一个类应该只负责一项职责。如类 A 负责两个不同职责：职责 1，职责 2。当职责 1 需求变更，而改变 A 时，可能造成职责 2 执行错误，所以需要将类 A 的粒度分解为 A1，A2。

1.2.1.2、代码示例

我们先浅浅的写一个交通工具的代码类。

package cn.linstudy.singleresponsibilityprinciple;

/**
 * @Description 单一职责原则
 * @Date 2023/4/8
 * @Author XiaoLin
 */
public class SingleResponsibility {
    public static void main(String[] args) {
        Vehicle vehicle = new Vehicle();
        vehicle.run("摩托车");
        vehicle.run("单车");
        vehicle.run("飞机");
    }
}

class Vehicle{
    public void run(String vehicle){
        System.out.println(vehicle+"在公路上跑");
    }
}

我们执行完以后发现了一个很奇怪的事情，飞机为什么可以在公路上跑？

出现这种问题的原因是因为run方法违反了单一职责的原则，解决方案也很简单，我们可以根据交通工具运行的方式来分解成不同的类去跑即可。我们把交通工具分解为路上跑的和天上飞的即可。

package cn.linstudy.singleresponsibilityprinciple;

/**
 * @Description 单一职责原则
 * @Date 2023/4/8
 * @Author XiaoLin
 */
public class SingleResponsibility {
    public static void main(String[] args) {
        RoadVehicle vehicle = new RoadVehicle();
        vehicle.run("摩托车");
        vehicle.run("单车");
        SkyVehicle skyVehicle = new SkyVehicle();
        skyVehicle.run("飞机");
    }
}


class RoadVehicle {
    public void run(String vehicle){
        System.out.println(vehicle+"在公路上跑");
    }
}

class SkyVehicle {
    public void run(String vehicle){
        System.out.println(vehicle+"在天上飞");
    }
}

这个方案遵守了单一职责原则，但是这样做改动或者说花销很大，即要将这个类分解，同时还需要修改客户端，所以我们可以在一开始的代码中修改，直接写成一个Vehicle类，但是里面使用方法来区分。

package cn.linstudy.singleresponsibilityprinciple;

/**
 * @Description 单一职责原则
 * @Date 2023/4/8
 * @Author XiaoLin
 */
public class SingleResponsibility {
    public static void main(String[] args) {
        Vehicle vehicle = new Vehicle();
        vehicle.roadRun("摩托车");
        vehicle.roadRun("单车");
        vehicle.skyRun("飞机");
    }
}
class Vehicle {
    public void roadRun(String vehicle){
        System.out.println(vehicle+"在公路上跑");
    }

    public void skyRun(String vehicle){
        System.out.println(vehicle+"在天上飞");
    }
}

这种改动虽然没有在类上遵守了单一职责原则，但是在方法上遵守了单一职责原则，简单来说就是各个方法各司其职

1.2.1.3、小结

降低类的复杂度，一个类只负责一项职责。
提高类的可读性，可维护性
降低变更引起的风险
通常情况下，我们应当遵守单一职责原则，只有逻辑足够简单，才可以在代码级违反单一职责原则，只有类中方法数量足够少，可以在方法级别保持单一职责原则。

1.2.2、接口隔离原则

1.2.2.1、基本介绍

客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上

1.2.2.2、代码示例

我们先来写一个错误的写法。

package cn.linstudy.Interfacesegregationprinciple;

/**
 * @Description
 * @Date 2023/4/8
 * @Author XiaoLin
 */
public class InterfaceSegregation {
}

interface Interface1 {
    void operation1();

    void operation2();
    void operation3();
    void operation4();
    void operation5();
}

class B implements Interface1 {

    @Override
    public void operation1() {
        System.out.println("类B实现了operation1");
    }

    @Override
    public void operation2() {
        System.out.println("类B实现了operation2");
    }

    @Override
    public void operation3() {
        System.out.println("类B实现了operation3");
    }

    @Override
    public void operation4() {
        System.out.println("类B实现了operation4");
    }

    @Override
    public void operation5() {
        System.out.println("类B实现了operation5");
    }
}

class D implements Interface1 {

    @Override
    public void operation1() {
        System.out.println("类D实现了operation1");
    }

    @Override
    public void operation2() {
        System.out.println("类D实现了operation2");
    }

    @Override
    public void operation3() {
        System.out.println("类D实现了operation3");
    }

    @Override
    public void operation4() {
        System.out.println("类D实现了operation4");
    }

    @Override
    public void operation5() {
        System.out.println("类D实现了operation5");
    }
}

/**
 * 类A通过接口Interface1依赖B类，但是只会用到其中的1、2、3这三个方法
 */
class ClassA {

    public void depend1(Interface1 interface1){
        interface1.operation1();
    }
    public void depend2(Interface1 interface2){
        interface2.operation2();
    }

    public void depend3(Interface1 interface3){
        interface3.operation3();
    }
}

/**
 * 类B通过接口Interface1依赖D类，但是只会用到其中的1、4、5这三个方法
 */
class ClassB {

    public void depend1(Interface1 interface1){
        interface1.operation1();
    }
    public void depend4(Interface1 interface2){
        interface2.operation4();
    }

    public void depend5(Interface1 interface3){
        interface3.operation5();
    }
}

我们可以发现，如果这样写的话，Interface1的4、5两个方法是白写的，同理Interface2的2、3这两个方法也是白写的，所以我们就需要去改进。改进的方法也很简单，大致可以分为三步：

类 A 通过接口 Interface1 依赖类 B，类 C 通过接口 Interface1 依赖类 D，如果接口 Interface1 对于类 A 和类 C 来说不是最小接口，那么类 B 和类 D 必须去实现他们不需要的方法.
将接口 Interface1 拆分为独立的几个接口，类 A 和类 C 分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则.
接口 Interface1 中出现的方法，根据实际情况拆分为三个接口

package cn.linstudy.Interfacesegregationprinciple;

/**
 * @Description
 * @Date 2023/4/8
 * @Author XiaoLin
 */
public class InterfaceSegregation {
    public static void main(String[] args) {
        ClassA clasA = new ClassA();
        // A 类通过接口去依赖 B 类
        clasA.depend1(new B());
        clasA.depend2(new B());
        clasA.depend3(new B());

        ClassB clasB = new ClassB();
        // C类通过接口去依赖(使用)D 
        clasB.depend1(new D());
        clasB.depend4(new D());
        clasB.depend5(new D());
    }
}

/**
 * 接口 1
 */
interface Interface1 {
    void operation1();
}

/**
 * 接口 2
 */
interface Interface2 {
    void operation2();
    void operation3();
}

/**
 * 接口 3
 */
interface Interface3 {
    void operation4();
    void operation5();
}
class B implements Interface1, Interface2 {

    public void operation1() {
        System.out.println("B 实现了 operation1");
    }
    public void operation2() {
        System.out.println("B 实现了 operation2");
    }
    public void operation3() {
        System.out.println("B 实现了 operation3");
    }
}
class D implements Interface1, Interface3 {
    public void operation1() {
        System.out.println("D 实现了 operation1");
    }
    public void operation4() {
        System.out.println("D 实现了 operation4");
    }
    public void operation5() {
        System.out.println("D 实现了 operation5");
    }
}

/**
 * 类A通过接口Interface1依赖B类，但是只会用到其中的1、2、3这三个方法
 */
class ClassA {

    public void depend1(Interface1 i) {
        i.operation1();
    }
    public void depend2(Interface2 i) {
        i.operation2();
    }
    public void depend3(Interface2 i) {
        i.operation3();
    }
}

/**
 * 类B通过接口Interface1依赖D类，但是只会用到其中的1、4、5这三个方法
 */
class ClassB {

    public void depend1(Interface1 i) {
        i.operation1();
    }
    public void depend4(Interface3 i) {
        i.operation4();
    }
    public void depend5(Interface3 i) {
        i.operation5();
    }
}

1.2.3、依赖倒转原则

1.2.3.1、基本介绍

依赖倒转原则(Dependence Inversion Principle)是指：

高层模块不应该依赖低层模块，二者都应该依赖其抽象.
抽象不应该依赖细节，细节应该依赖抽象.
依赖倒转(倒置)的中心思想是面向接口编程.
依赖倒转原则是基于这样的设计理念：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在 java 中，抽象指的是接口或抽象类，细节就是具体的实现类.
使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成.

1.2.3.2、代码实现

package cn.linstudy.dependenceinversionprinciple;

/**
 * @Description 依赖倒转原则
 * @Date 2023/4/8
 * @Author XiaoLin
 */
public class DependenceInversion {
}

class Email {
    public String getInfo(){
        return "我是电子邮件：hello,world";
    }
}

class People{
    public void receive(Email email){
        System.out.println(email.getInfo() );
    }
}

我们会发现，这种方式比较简单，但是也有一个很致命的问题，那就是如果我们接受的对象不是消息对象，是短信、微信等其他的对象，则需要新增类，同时people对象的话也需要新增对应的接收方法。所以我们需要去改一下这个代码逻辑。修改的思路也比较简单：

引入一个抽象的接口IReceiver，表示接受者，这样People类与IReceiver发生依赖。
Email、Wechat等对象也是属于接受者范围，他们各自实现IReceiver接口就可以了。

package cn.linstudy.dependenceinversionprinciple.improve;

/**
 * @Description 改进后的依赖倒转原则
 * @Date 2023/4/8
 * @Author XiaoLin
 */
public class DependenceInversion {
    public static void main(String[] args) {
        People people = new People();
        people.receive(new Email());
    }
}

/**
 * 定义接口
 */
interface IReceiver{
    public String getInfo();
}

class Email implements IReceiver{
    public String getInfo(){
        return "我是电子邮件：hello,world";
    }
}

class People{
    public void receive(IReceiver receiver){
        System.out.println(receiver.getInfo() );
    }
}

1.2.3.3、依赖关系传递的三种方式

接口传递
构造方法传递
setter方法传递

1.2.3.4、小结

低层模块尽量都要有抽象类或接口，或者两者都有，程序稳定性更好.
变量的声明类型尽量是抽象类或接口, 这样我们的变量引用和实际对象间，就存在一个缓冲层，利于程序扩展和优化.
继承时遵循里氏替换原则.

1.2.4、里氏替换原则

1.2.4.1、继承的弊端

继承包含这样一层含义：父类中凡是已经实现好的方法，实际上是在设定规范和契约，虽然它不强制要求所有的子类必须遵循这些契约，但是如果子类对这些已经实现的方法任意修改，就会对整个继承体系造成破坏。

继承在给程序设计带来便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能产生故障，那么我们在写代码的过程中如何正确的使用继承呢？答案是遵循里氏替换原则。

1.2.4.2、里氏替换原则

里氏替换原则(Liskov Substitution Principle)在 1988 年，由麻省理工学院的以为姓里的女士提出的。

如果对每个类型为 T1 的对象 o1，都有类型为 T2 的对象 o2，使得以 T1 定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。换句话说，所有引用基类的地方必须能透明地使用其子类的对象。

在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类的方法，里氏替换原则告诉我们，继承实际上让两个类耦合性增强了，在适当的情况下，可以通过聚合，组合，依赖来解决问题。.

1.2.4.3、代码示例

package cn.linstudy.dependenceinversionprinciple;


/**
 * @Description
 * @Date 2023/4/8
 * @Author XiaoLin
 */
public class Liskov {

    public static void main(String[] args) {
// TODO Auto-generated method stub
        A a = new A();
        System.out.println("11-3=" + a.func1(11, 3));
        System.out.println("1-8=" + a.func1(1, 8));
        System.out.println("-----------------------");
        B b = new B();
        //这里本意是求出 11-3
        System.out.println("11-3=" + b.func1(11, 3));
        // 1-8
        System.out.println("1-8=" + b.func1(1, 8));
        System.out.println("11+3+9=" + b.func2(11, 3));
    }
}

/**
 * A 类
 */
class A {
    // 返回两个数的差
    public int func1(int num1, int num2) {
        return num1 - num2;
    }
}

/**
 * B 类继承了 A , 增加了一个新功能：完成两个数相加,然后和 9 求和
 */

class B extends A {
    //这里，重写了 A 类的方法, 可能是无意识
    public int func1(int a, int b) {
        return a + b;
    }
    public int func2(int a, int b) {
        return func1(a, b) + 9;
    }
}

我们发现原来运行正常的相减功能发生了错误。原因就是类 B 无意中重写了父类的方法，造成原有功能出现错误。在实际编程中，我们常常会通过重写父类的方法完成新的功能，这样写起来虽然简单，但整个继承体系的复用性会比较差。特别是运行多态比较频繁的时候，这个时候通用的解决办法是原来的父类和子类都继承一个更通俗的基类，原有的继承关系去掉，采用依赖，聚合，组合等关系代替。

轻松掌握Java设计模式，打造高质量代码（一）