Java软件设计的七大原则

最新推荐文章于 2023-08-03 18:12:33 发布

Jarvis.y

最新推荐文章于 2023-08-03 18:12:33 发布

阅读量361

点赞数 1

分类专栏： java设计模式架构师学习笔记文章标签： java 设计模式

本文链接：https://blog.csdn.net/weixin_38024782/article/details/108558057

版权

架构师学习笔记同时被 2 个专栏收录

39 篇文章 4 订阅

订阅专栏

java设计模式

12 篇文章 0 订阅

订阅专栏

摘抄blog：
https://www.cnblogs.com/bert227/p/10897328.html
https://www.cnblogs.com/o-andy-o/p/10315188.html

0、七大设计原则

开闭原则（Open-Closed Preinciple，OCP）
指一个软件实体比如类、模块、函数应该对扩展开放，对修改关闭。
所谓的开闭，也正是对扩展和修改两个行为的一个原则。强调的是用抽象构建框架，用实现扩展细节。就是可以新增功能，但是不建议修改原有底层代码。开闭原则可以提高软件系统的可复用性及可维护性，是面向对象设计中最基础的设计原则，核心思想就是面向抽象编程。
依赖倒置原则（Dependence Inversion Principle，DIP）
指设计代码结构时，高层模块不应该依赖底层模块，二者都应该依赖其抽象。抽象不应该依赖细节；细节应该依赖缓抽象。针对接口编程不应该针对实现编程。
通过依赖倒置，可以减少类与类的之间的耦合性，提高系统的稳定性，提高代码的可读性和可维护性，并且能够降低修改程序所造成的风险。
单一职能原则（Simple Responsibility Pinciple，SRP）
指不要存在多于一个导致类变更的原因。
假设我们有一个 Class 负责两个职责，一旦发生需求变更，修改其中一个职责的逻辑代码，有可能会导致另一个职责的功能发生故障。这样一来，这个 Class 存在两个导致类变更的原因。如何解决这个问题呢？我们就要给两个职责分别用两个 Class 来实现，进行解耦。后期需求变更维护互不影响。这样的设计，可以降低类的复杂度，提高类的可读性，提高系统的可维护性，降低变更引起的风险。总体来说就是一个Class/Interface/Method 只负责一项职责。
接口隔离原则（Interface Segregation Principle，ISP）
指用多个专门的接口，而不使用单一的总接口，客户端不应该依赖它不需要的接口。
这个原则指导我们在设计接口时，应当注意以下几点：
- 一个类对一类的依赖应该建立在最小的接口之上
- 建立单一接口，不要建立庞大臃肿的接口
- 尽量细化接口，接口中的方法尽量少（不是越少越好，一定要适度）
接口隔离原则符合我们常说的高内聚低耦合的设计思想，从而使得类具有很好的可读性，可扩展性和可维护性。所以我们在设计接口的时候要考虑业务模型，以后可能发生变更的地方。
迪米特原则（Law of Demeter LoD）又叫最少知道原则（Least KnowIedge Principle，LKP）
指一个对象应该对其他对象保持最少的了解，尽量降低类与类之间的耦合。
迪米特原则主要强调只和朋友交流，不和陌生人说话。出现在成员变量，方法的输入，输出参数中的类都可以称之为成员朋友类，而出现在方法体内部的类不属于朋友类。
里氏替换原则（Liskov Substitution Principle， LSP）
指如果对每一个类型为 T1 的对象 o1,都有类型为 T2 的对象 o2,使得以 T1 定义的所有程序 P 在所有的对象 o1 都替换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。
可以理解为一个软件实体如果适用一个父类的话，那一定是适用于其子类，所有引用父类的地方必须能透明地使用其子类的对象，子类对象能够替换父类对象，而程序逻辑不变。根据这个理解，我们总结一下：引申含义：子类可以扩展父类的功能，但不能改变父类原有的功能。
1. 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
2. 子类中可以增加自己特有的方法。
3. 当子类的方法重载父类的方法时，方法的前置条件（即方法的输入/入参）要比父类方法的输入参数更宽松。
4. 当子类的方法实现父类的方法时（重写/重载或实现抽象方法），方法的后置条件（即方法的输出/返回值）要比父类更严格或相等。
使用里氏替换原则有以下优点：
1. 约束继承泛滥，开闭原则的一种体现。
2. 加强程序的健壮性，同时变更时也可以做到非常好的兼容性，提高程序的维护性、扩展性。降低需求变更时引入的风险。
合成复用原则（ Composite/Aggregate Reuse Principle，CARP）
指尽量使用对象组合(has-a)/聚合(contanis-a)，而不是继承关系达到软件复用的目的。
可以使系统更加灵活，降低类与类之间的耦合度，一个类的变化对其他类造成的影响相对较少。继承我们叫做白箱复用，相当于把所有的实现细节暴露给子类。组合/聚合也称之为黑箱复用，对类以外的对象是无法获取到实现细节的。要根据具体的业务场景来做代码设计，其实也都需要遵循 OOP 模型。

1、开闭原则（Open-Closed Preinciple，OCP）

定义：指一个软件实体比如类、模块、函数应该对扩展开放，对修改关闭。
所谓的开闭，也正是对扩展和修改两个行为的一个原则。强调的是用抽象构建框架，用实现扩展细节。就是可以新增功能，但是不建议修改原有底层代码。开闭原则可以提高软件系统的可复用性及可维护性，是面向对象设计中最基础的设计原则，核心思想就是面向抽象编程。
具体代码：
1、定义Car接口

package com.jarvisy.demo.design.ocp;


/**
* @author : Jarvisy
* @date : 2020/9/12
* @description : 车接口
*/
public interface Car {
    Integer getId();
    String getName();
    Double getPrice();
}

2、定义宝马车

package com.jarvisy.demo.design.ocp;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/12 18:17
* @description ： 宝马车
*/
public class BWMCar implements Car {


    private Integer id;
    private String name;
    private Double price;


    public BWMCar(Integer id, String name, Double price) {
        this.id = id;
        this.name = name;
        this.price = price;
    }


    @Override
    public Integer getId() {
        return this.id;
    }


    @Override
    public String getName() {
        return this.name;
    }


    @Override
    public Double getPrice() {
        return this.price * 0.8;
    }
}

3、新建测试类

package com.jarvisy.demo.design.ocp;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/12 18:23
* @description：
*/
public class Test {
    public static void main(String[] args) {
        Car car = new BWMCar(100, "宝马车", 100d);
        System.out.println("车id:" + car.getId() + "  车名称：" + car.getName() + "  车价格:" + car.getPrice());
    }
}

此时车的功能就已经做好，但是当车搞活动打8折怎么办？
方法一：在Car接口中添加打折接口：

Double getDiscountPrice();

然后需要在实现了Car接口的实现类中都实现打折接口：

@Override
public Double getDiscountPrice() {
    return this.price * 0.8;
}

然后在测试类中调用打折接口：

System.out.println("车id:" + car.getId() + "  车名称：" + car.getName() + "  车价格:" + car.getDiscountPrice());

这样一来，如果Car很多的话，那么所有的Car都需要加上打折接口。比如有些不需要打折的Car。接口不能随便动，否则作为契约的作用就失去了。

方法二：直接改BWMCar 中的实现逻辑：

@Override
public Double getPrice() {
    return this.price*0.8;
}

这个有什么问题呢？同上面一样，如果Car很多的话，修改的地方就有很多，如果需要调回原价，或者说又添加新的需求比如优惠卷的活动怎么办，不能每次都修改实现逻辑吧？

方法三：新增一个BWMCarForDisCount打折类，继承BWMCar类：

package com.jarvisy.demo.design.ocp;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/12 18:44
* @description ：宝马车打折促销
*/
public class BWMCarForDisCount extends BWMCar {


    public BWMCarForDisCount(Integer id, String name, Double price) {
        super(id, name, price);
    }


    /**
     * 打折折扣
     *
     * @return
     */
    @Override
    public Double getPrice() {
        return super.getPrice() * 0.8;
    }
}

2、依赖倒置原则（Dependence Inversion Principle，DIP）

定义：指设计代码结构时，高层模块不应该依赖底层模块，二者都应该依赖其抽象。抽象不应该依赖细节；细节应该依赖缓抽象。针对接口编程，不应该针对实现编程。
通过依赖倒置，可以减少类与类的之间的耦合性，提高系统的稳定性，提高代码的可读性和可维护性，并且能够降低修改程序所造成的风险。
具体代码：
首先创建一个MyCar类，假如你现在有两辆车：

package com.jarvisy.demo.design.dip;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/12 19:10
* @description：
*/
public class MyCar {
    public void AudiCar() {
        System.out.println("AudiCar  is drving ……");
    }


    public void BWMCar() {
        System.out.println("BWMCar is drving ……");
    }
}

但是随着生活越来越好，又买了一辆车，这个时候，业务扩展，我们的代码要从底层到高层（调用层）依次修改代码。在MyCar类中新增XXXCarDriving()的方法，在高成也追加调用，如此一来，已经稳定的代码或者说生产上的代码被修改了，实际上这是非常危险的一件事，在修改代码的同时可能会带来意象不到的风险。所以我们优化一下代码，创建一个Car的接口。

package com.jarvisy.demo.design.dip;


/**
* @author     ：Jarvisy
* @date       ：Created in 2020/9/12 19:24
* @description：
*/
public interface Car {
    /**
     * 驾驶
     */
    void driving();
}

创建car实现类：

package com.jarvisy.demo.design.dip;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/12 19:27
* @description： 奥迪车
*/
public class AudiCar implements Car {
    @Override
    public void driving() {
        System.out.println(this.getClass().getSimpleName() + "is driving ……");
    }
}

package com.jarvisy.demo.design.dip;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/12 19:30
* @description ： 宝马车
*/
public class BWMCar implements Car {


    @Override
    public void driving() {
        System.out.println(this.getClass().getSimpleName() + "is driving ……");
    }
}

创建我的car：

package com.jarvisy.demo.design.dip;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/12 19:10
* @description ： 我的车
*/
public class MyCar {
    /**
     * 驾驶
     *
     * @param car
     */
    public void driving(Car car) {
        car.driving();
    }
}

创建测试类：

package com.jarvisy.demo.design.dip;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/12 19:33
* @description ：
*/
public class Test {
    public static void main(String[] args) {
        MyCar myCar = new MyCar();
        myCar.driving(new AudiCar());
        myCar.driving(new BWMCar());
    }
}

这个时候再来看代码，无论你有多少车，对于新车，我只需要新建一类，通过传参的方式告诉MyCar，而不需要修改底层代码。实际上这是一种大家非常熟悉的方式，叫依赖注入。
注入的方式还有构造器方式和 setter 方式。
我们来看构造器注入方式：
新建MyCarByConstructor类：

package com.jarvisy.demo.design.dip;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/12 19:44
* @description ：由构造器注入
*/
public class MyCarByConstructor {


    private Car car;


    public MyCarByConstructor(Car car) {
        this.car = car;
    }


    public void driving() {
        car.driving();
    }
}

修改测试类：

package com.jarvisy.demo.design.dip;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/12 19:33
* @description ：
*/
public class Test {
    public static void main(String[] args) {
        new MyCarByConstructor(new AudiCar()).driving();
        new MyCarByConstructor(new BWMCar()).driving();
    }
}

根据构造器方式注入，在调用时，每次都要创建实例。那么，如果 MyCar 是全局单例，则我们就只能选择用 Setter 方式来注入，
新建 MyCarBySetter 类：

package com.jarvisy.demo.design.dip;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/12 19:44
* @description ：由set注入
*/
public class MyCarBySetter {


    private Car car;


    public void setCar(Car car) {
        this.car = car;
    }


    public void driving() {
        car.driving();
    }
}

修改测试类：

package com.jarvisy.demo.design.dip;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/12 19:33
* @description ：
*/
public class Test {
    public static void main(String[] args) {
       
        MyCarBySetter myCarBySetter = new MyCarBySetter();
        myCarBySetter.setCar(new AudiCar());
        myCarBySetter.driving();
        myCarBySetter.setCar(new BWMCar());
        myCarBySetter.driving();
    }
}

3、单一职能原则（Simple Responsibility Pinciple，SRP）

定义：指不要存在多于一个导致类变更的原因。
假设我们有一个 Class 负责两个职责，一旦发生需求变更，修改其中一个职责的逻辑代码，有可能会导致另一个职责的功能发生故障。这样一来，这个 Class 存在两个导致类变更的原因。如何解决这个问题呢？我们就要给两个职责分别用两个 Class 来实现，进行解耦。后期需求变更维护互不影响。
这样的设计，可以降低类的复杂度，提高类的可读性，提高系统的可维护性，降低变更引起的风险。总体来说就是一个Class/Interface/Method 只负责一项职责。
具体代码：
创建DriveCar类：

package com.jarvisy.demo.design.srp;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/12 20:26
* @description ：驾驶car
*/
public class DriveCar {


    /**
     * 驾驶
     *
     * @param carType 车类型
     */
    public void driving(String carType) {
        if ("SUV".equals(carType)) {
            System.out.println(carType + "动力强悍，适合越野");
        } else {
            System.out.println(carType + "乘坐舒适");
        }
    }
}

创建测试类：

package com.jarvisy.demo.design.srp;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/12 20:29
* @description ：
*/
public class Test {
    public static void main(String[] args) {
        DriveCar driveCar = new DriveCar();
        driveCar.driving("SUV");
        driveCar.driving("MPV");
    }
}

从代码看,DriveCar有两种职能，一个是SUV车，一个是MPV车。假如需要加入新的需求，要对SUV做更多的处理，那么SUV，MPV的大小，功能都不一样，就必须要修改代码。而修改代码逻辑势必会影响MPV的功能，容易造成不可控的风险，我们就需要对职能进行解耦。
我们分别创建两个类SUVDrive 和 MPVDrive：

package com.jarvisy.demo.design.srp;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/12 20:35
* @description ：驾驶MVP车
*/
public class MPVDrive {
    public void driving(String carType) {
        System.out.println(carType + "乘坐舒适");
    }
}

package com.jarvisy.demo.design.srp;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/12 20:36
* @description ：驾驶SUV车
*/
public class SUVDrive {
    public void driving(String carType) {
        System.out.println(carType + "动力强悍，适合越野");
    }
}

修改测试类：

package com.jarvisy.demo.design.srp;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/12 20:29
* @description ：
*/
public class Test {
    public static void main(String[] args) {
      
        SUVDrive suv = new SUVDrive();
        suv.driving("SUV");
        MPVDrive mpv = new MPVDrive();
        mpv.driving("MPV");
    }
}

如果有跟多的业务需要，可以设计一个顶层接口或者一个抽象类集成通用DriveCar功能，然后再根据情况拆分成不同的接口或者抽象类，使其满足单一职责原则，便于后期维护。

4、接口隔离原则（Interface Segregation Principle，ISP）

定义：指用多个专门的接口，而不使用单一的总接口，客户端不应该依赖它不需要的接口。
这个原则指导我们在设计接口时，应当注意以下几点：

一个类对一类的依赖应该建立在最小的接口之上
建立单一接口，不要建立庞大臃肿的接口
尽量细化接口，接口中的方法尽量少（不是越少越好，一定要适度）

接口隔离原则符合我们常说的高内聚低耦合的设计思想，从而使得类具有很好的可读性，可扩展性和可维护性。所以我们在设计接口的时候要考虑业务模型，以后可能发生变更的地方。
具体代码：
首先我们创建Animal接口：

package com.jarvisy.demo.design.isp;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/12 20:53
* @description ：动物接口
*/
public interface Animal {
    /**
     * 吃
     */
    void eat();


    /**
     * 飞
     */
    void fly();


    /**
     * 游
     */
    void swim();
}

然后我们再创建动物的实现类:

package com.jarvisy.demo.design.isp;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/12 20:53
* @description ：鸟
*/
public class Bird implements Animal {
    @Override
    public void eat() {
    }


    @Override
    public void fly() {
    }


    @Override
    public void swim() {
    }
}

package com.jarvisy.demo.design.isp;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/12 20:53
* @description ：狗
*/
public class Dog implements Animal {
    @Override
    public void eat() {
    }


    @Override
    public void fly() {
    }


    @Override
    public void swim() {
    }
}

可以看出，Bird 的 swim()方法可能只能空着，Dog 的 fly()方法显然不可能的。这时候，我们针对不同动物行为来设计不同的接口，分别设计 IEatAnimal，IFlyAnimal 和 ISwimAnimal 接口。

package com.jarvisy.demo.design.isp;
/**
* @author ：Jarvisy
* @date ：Created in 2020/9/12 20:56
* @description ：动物吃的接口
*/
public interface EatAnimal {
    void eat();
}

package com.jarvisy.demo.design.isp;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/12 20:56
* @description ：动物飞行的接口
*/
public interface FlyAnimal {
    void fly();
}

package com.jarvisy.demo.design.isp;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/12 20:57
* @description ：动物游泳的接口
*/
public interface SwimAnimal {
    void swim();
}

然后我们再来修改Dog实现类，这时我们只要实现SwimAnimal，EatAnimal接口就可以了。

package com.jarvisy.demo.design.isp;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/12 20:53
* @description ：狗
*/
public class Dog implements EatAnimal,SwimAnimal {
    @Override
    public void eat() {
    }


    @Override
    public void swim() {
    }
}

5、迪米特法则（Law of Demeter LoD）又叫最少知道原则（Least KnowIedge Principle，LKP）

定义：指一个对象应该对其他对象保持最少的了解，尽量降低类与类之间的耦合。
迪米特原则主要强调只和朋友交流，不和陌生人说话。出现在成员变量，方法的输入，输出参数中的类都可以称之为成员朋友类，而出现在方法体内部的类不属于朋友类。现在来设计一个权限系统，Boss需要查看目前发布到线上的课程数量。这个时候，Boss要找到TeamLeader去进行统计，TeamLeader再把统计结果告诉Boss。
具体代码：
首先创建课程类：

package com.jarvisy.demo.design.lkp;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/12 22:52
* @description ：课程类
*/
public class Course {
}

然后创建TeamLeader类：

package com.jarvisy.demo.design.lkp;


import java.util.List;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/12 22:53
* @description ：团队领导类
*/
public class TeamLeader {
    /**
     * 统计课程数量
     *
     * @param courseList
     */
    public void checkNumberOfCourses(List<Course> courseList) {
        System.out.println("目前已发布的课程数量是：" + courseList.size());
    }
}

创建Boss类：

package com.jarvisy.demo.design.lkp;


import java.util.ArrayList;
import java.util.List;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/12 22:54
* @description ：Boss类
*/
public class Boss {
    /**
     * 模拟boss找teamLeader统计课程数
     *
     * @param teamLeader
     */
    public void commandCheckNumber(TeamLeader teamLeader) {
        //模拟 Boss 一页一页往下翻页，TeamLeader 实时统计
        List<Course> courseList = new ArrayList<>();
        for (int i = 0; i < 20; i++) {
            courseList.add(new Course());
        }
        teamLeader.checkNumberOfCourses(courseList);
    }
}

创建测试类：

package com.jarvisy.demo.design.lkp;


import com.jarvisy.demo.design.ocp.BWMCar;
import com.jarvisy.demo.design.ocp.Car;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/12 18:23
* @description ：
*/
public class Test {
    public static void main(String[] args) {
        Boss boss = new Boss();
        TeamLeader teamLeader = new TeamLeader();
        boss.commandCheckNumber(teamLeader);
    }
}

从上述代码看上去也没什么问题。根据迪米特原则，Boss 只想要结果，不需要跟 Course 产生直接的交流。而 TeamLeader 统计需要引用 Course 对象。但是从下面的类图就可以看出来：Boss 和 Course 还是产生了关联。
在这里插入图片描述
我们对代码修改一下：
Boss类修改：

package com.jarvisy.demo.design.lkp;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/12 22:54
* @description ：Boss类
*/
public class Boss {
    /**
     * 模拟boss找teamLeader统计课程数
     *
     * @param teamLeader
     */
    public void commandCheckNumber(TeamLeader teamLeader) {
        teamLeader.checkNumberOfCourses();
    }
}

TeamLeaders类：

package com.jarvisy.demo.design.lkp;


import java.util.ArrayList;
import java.util.List;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/12 22:53
* @description ：团队领导类
*/
public class TeamLeader {
    /**
     * 统计课程数量
     */
    public void checkNumberOfCourses() {
        List<Course> courseList = new ArrayList<>();
        for (int i = 0; i < 20; i++) {
            courseList.add(new Course());
        }
        System.out.println("目前已发布的课程数量是：" + courseList.size());
    }
}

再来看类图：
在这里插入图片描述
此时Course和Boss已经没有关系了。

6、里氏替换原则（Liskov Substitution Principle， LSP）

定义：指如果对每一个类型为 T1 的对象 o1,都有类型为 T2 的对象 o2,使得以 T1 定义的所有程序 P 在所有的对象 o1 都替换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。
可以理解为一个软件实体如果适用一个父类的话，那一定是适用于其子类，所有引用父类的地方必须能透明地使用其子类的对象，子类对象能够替换父类对象，而程序逻辑不变。根据这个理解，我们总结一下：引申含义：子类可以扩展父类的功能，但不能改变父类原有的功能。

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

使用里氏替换原则有以下优点：

约束继承泛滥，开闭原则的一种体现。
加强程序的健壮性，同时变更时也可以做到非常好的兼容性，提高程序的维护性、扩展性。降低需求变更时引入的风险。

具体代码：
针对于：子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。 这一条原则测试。
现在来描述一个经典的业务场景，用正方形、矩形和四边形的关系说明里氏替换原则，我们都知道正方形是一个特殊的长方形，那么就可以创建一个长方形父类 Rectangle 类：

package com.jarvisy.demo.design.lsp;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/13 0:52
* @description ：长方形父类
*/
public class Rectangle {
    private long height;
    private long width;


    public long getWidth() {
        return width;
    }


    public void setWidth(long width) {
        this.width = width;
    }


    public long getHeight() {
        return height;
    }


    public void setHeight(long height) {
        this.height = height;
    }
}

创建正方形，继承长方形父类Rectangle：

package com.jarvisy.demo.design.lsp;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/13 0:52
* @description ：正方形 继承Rectangle
*/
public class Square extends Rectangle {
    private long length;


    public long getLength() {
        return length;
    }


    public void setLength(long length) {
        this.length = length;
    }


    @Override
    public long getWidth() {
        return getLength();
    }


    @Override
    public long getHeight() {
        return getLength();
    }


    @Override
    public void setHeight(long height) {
        setLength(height);
    }


    @Override
    public void setWidth(long width) {
        setLength(width);
    }
}

创建测试类：

package com.jarvisy.demo.design.lsp;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/12 18:23
* @description ：
*/
public class Test {
    public static void resize(Rectangle rectangle) {
        while (rectangle.getWidth() >= rectangle.getHeight()) {
            rectangle.setHeight(rectangle.getHeight() + 1);
            System.out.println("width:" + rectangle.getWidth() + ",height:" + rectangle.getHeight());
        }
        System.out.println("resize 方法结束" + " width:" + rectangle.getWidth() + ",height:" + rectangle.getHeight());
    }


    public static void main(String[] args) {
        Rectangle rectangle = new Rectangle();
        rectangle.setWidth(20);
        rectangle.setHeight(10);
        resize(rectangle);
    }
}

运行结果：

width:20,height:11
width:20,height:12
width:20,height:13
width:20,height:14
width:20,height:15
width:20,height:16
width:20,height:17
width:20,height:18
width:20,height:19
width:20,height:20
width:20,height:21
resize 方法结束 width:20,height:21

发现高比宽还大了，在长方形中是一种非常正常的情况。现在我们再来看下面的代码，把长方形 Rectangle 替换成它的子类正方形 Square，修改测试代码：

package com.jarvisy.demo.design.lsp;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/12 18:23
* @description ：针对于：子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。这一条原则测试
*/
public class Test {
    public static void resize(Rectangle rectangle) {
        while (rectangle.getWidth() >= rectangle.getHeight()) {
            rectangle.setHeight(rectangle.getHeight() + 1);
            System.out.println("width:" + rectangle.getWidth() + ",height:" + rectangle.getHeight());
        }
        System.out.println("resize 方法结束" + " width:" + rectangle.getWidth() + ",height:" + rectangle.getHeight());
    }


    public static void main(String[] args) {
       
        Square square = new Square();
        square.setLength(10);
        resize(square);
    }
}

这时候我们运行的时候就出现了死循环，将父类替换为子类后，程序运行结果没有达到预期。这里就是因为违背了里氏替换原则，子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。

package com.jarvisy.demo.design.lsp;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/13 1:38
* @description ：针对于：子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。这一条原则测试
*/
public class LSP0 {


    class A {
        public void fun() {
            System.out.println("父类被执行...");
        }
    }


    class B extends A {
        public void fun() {
            System.out.println("子类被执行...");
        }
    }


    public static void main(String[] args) {
        System.out.print("父类的运行结果：");
        LSP0 lsp = new LSP0();
        LSP0.A a = lsp.new A();
        a.fun();
        //父类存在的地方，可以用子类替代
        //子类B替代父类A
        System.out.print("子类替代父类后的运行结果：");
        LSP0.B b = lsp.new B();
        b.fun();
    }


}

此段代码子类重写了父类的fun()方法，将父类替换为子类后，程序逻辑发生变化。这里就是因为违背了里氏替换原则，子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。

针对于：当子类的方法重载父类的方法时，方法的前置条件（即方法的输入/入参）要比父类方法的输入参数更宽松。 这一条原则测试。

package com.jarvisy.demo.design.lsp;


import java.util.HashMap;
import java.util.Map;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/13 1:38
* @description ：针对于：当子类的方法重载父类的方法时，方法的前置条件（即方法的输入/入参）要比父类 方法的输入参数更宽松。这一条原则测试
*/
public class LSP {


    class A {
        public void fun(Map map) {
            System.out.println("父类被执行...");
        }
    }


    class B extends A {
        public void fun(HashMap map) {
            System.out.println("子类被执行...");
        }
    }


    public static void main(String[] args) {
        System.out.print("父类的运行结果：");
        LSP lsp = new LSP();
        LSP.A a = lsp.new A();
        HashMap<Object, Object> map = new HashMap<Object, Object>();
        a.fun(map);
        //父类存在的地方，可以用子类替代
        //子类B替代父类A
        System.out.print("子类替代父类后的运行结果：");
        LSP.B b = lsp.new B();
        b.fun(map);
    }


}

测试结果：

父类的运行结果：父类被执行...
子类替代父类后的运行结果：子类被执行...

此段测试代码子类重载了父类fun()方法并且入参比父类参数更小，违背了 当子类的方法重载父类的方法时，方法的前置条件（即方法的输入/入参）要比父类方法的输入参数更宽松。 所以执行了子类的方法，子类替换父类后，程序逻辑发生了变化。

package com.jarvisy.demo.design.lsp;


import java.util.HashMap;
import java.util.Map;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/13 1:48
* @description ：针对于： 当子类的方法实现父类的方法时（重写/重载或实现抽象方法），方法的后置条件（即 方法的输出/返回值）要比父类更严格或相等。这一条原则测试
*/
public class LSP1 {
    abstract class A {
        public abstract HashMap fun();
    }


    class B extends A {
        @Override
        public Map fun() {
            Map b = new HashMap();
            b.put("b", "子类被执行...");
            return b;
        }
    }


    public static void main(String[] args) {
        LSP1 lsp = new LSP1();
        LSP1.A a = lsp.new B();
        System.out.println(a.fun());
    }


}

此段代码子类实现了父类fun()抽象方法并且返回参数比父类参数更大，违背了当子类的方法实现父类的方法时（重写/重载或实现抽象方法），方法的后置条件（即方法的输出/返回值）要比父类更严格或相等。 这一段代码编译报错。

7、合成复用原则（ Composite/Aggregate Reuse Principle，CARP）

定义：指尽量使用对象组合(has-a)/聚合(contanis-a)，而不是继承关系达到软件复用的目的。
可以使系统更加灵活，降低类与类之间的耦合度，一个类的变化对其他类造成的影响相对较少。继承我们叫做白箱复用，相当于把所有的实现细节暴露给子类。组合/聚合也称之为黑箱复用，对类以外的对象是无法获取到实现细节的。要根据具体的业务场景来做代码设计，其实也都需要遵循 OOP 模型。
首先看代码：

package com.jarvisy.demo.design.carp;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/13 2:33
* @description ：定义数据库连接类
*/
public class DBConnection {
    public String getConnection() {
        return "MySQL 数据库连接";
    }
}

package com.jarvisy.demo.design.carp;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/13 2:34
* @description ：定义操作数据的Dao
*/
public class ProductDao {
    private DBConnection dbConnection;


    public void setDbConnection(DBConnection dbConnection) {
        this.dbConnection = dbConnection;
    }


    public void addProduct() {
        String conn = dbConnection.getConnection();
        System.out.println("使用" + conn + "增加产品");
    }
}

这就是一种非常典型的合成复用原则应用场景。但是，目前的设计来说，DBConnection 还不是一种抽象，不便于系统扩展。目前的系统支持 MySQL 数据库连接，假设业务发生变化，数据库操作层要支持 Oracle 数据库。当然，我们可以在 DBConnection 中增加对 Oracle 数据库支持的方法。但是违背了开闭原则。其实，我们可以不必修改 Dao 的代码，将 DBConnection 修改为 abstract，来看代码：

package com.jarvisy.demo.design.carp;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/13 2:35
* @description ：定义数据库连接抽象类
*/
public abstract class DBConnection1 {
    public abstract String getConnection();
}

package com.jarvisy.demo.design.carp;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/13 2:36
* @description ：Mysql数据库连接
*/
public class MySQLConnection extends DBConnection1 {
    @Override
    public String getConnection() {
        return "MySQL 数据库连接";
    }
}

package com.jarvisy.demo.design.carp;


/**
* @author ：Jarvisy
* @date ：Created in 2020/9/13 2:36
* @description ：Oracle 连接
*/
public class OracleConnection extends DBConnection1 {
    @Override
    public String getConnection() {
        return "Oracle 数据库连接";
    }
}

附上其他合成复用原则解释blog
https://blog.csdn.net/u012361379/article/details/88605867
https://www.jianshu.com/p/056d0c2d5470

Jarvis.y

关注

1
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Java软件设计的七大原则

摘抄blog：https://www.cnblogs.com/bert227/p/10897328.htmlhttps://www.cnblogs.com/o-andy-o/p/10315188.html0、七大设计原则开闭原则依赖倒置原则单一职能原则接口隔离原则迪米特原则里氏替换原则合成复用原则1、开闭原则（Open-Closed Preinciple，OCP）定义：指一个软件实体比如类、模块、函数应该对扩展开放，对修改关闭所谓的开闭，也正是对扩展和修改两个行为的一个.
复制链接

扫一扫