Java设计模式--------面向对象七大设计原则

原创已于 2022-12-21 19:57:18 修改 · 1.7k 阅读

20 ·

CC 4.0 BY-SA版权

文章标签：

#java #设计模式 #python

于 2022-11-08 21:05:33 首次发布

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

文章目录

前言

例如：随着计算机的不断发展，程序学习这门技术也越来越重要，很多人都开启了学习java编程学习，本文就介绍了Java编程学习的七大基本原则。

面向对象设计原则一共有七个：开闭原则、里氏替换原则、依赖倒转原则、单一职责原则、接口隔离原则、组合/聚合复用原则、迪米特法则。

下面就仔细来介绍一下这些原则

提示：以下是本篇文章正文内容，下面案例可供参考

一、单一职责原则

对类来说，就是一个类应该只负责一项职责，这就是单一职责原则。

如果你有多个动机去修改一个类，那么这个类就有多个职责。这可能比较难理解，因为我们通常把一组职责放在一起思考。下面来看一个具体的例子。下面是一个 bird（调制解调器或者叫猫）的接口,以愤怒的小鸟为例来

package com.oop.day12;

/**
 * 以愤怒的小鸟游戏为li
 */
public interface Bird {
    void attack1();
    void attack2();
    void cry1();
    void cry2();
}

上面这个猫的接口中存在两个职责：第一个是攻击方式（attack1和attack2）;第二个是攻击时的叫声（cry1和cry2）。这两个职责应该被分开，因为：

它们没有共同点，而且通常会因为不同的原因被修改；
调用它们的代码通常属于应用的不同部分，而这部分代码也会因为不同的原因被修改。

下面是优化之后的

通过拆分猫的接口，我们可以在应用的其他部分将猫的设计分开来对待。虽然我们又在猫的实现中（Bird Implementation）将这两部分职责重新耦合在一起，但是除了初始化猫的代码以外，在使用面向接口编程的原则后，其他代码并不需要依赖于猫的实现。

SRP 是最简单的一个面向对象设计原则，但也是最难做正确的一个，因为我们习惯于将职责合并，而不是将它们分开来。找到并且拆分这些职责正是软件设计真正需要做的事情。

单一职责原则例子

package com.oop.day12;

public class Animal {
        public static void main(String[] args) {
            RoadAnimal roadAnimal = new RoadAnimal();
            //输出： 老虎 在森林里跑
            roadAnimal.run("老虎");
            //输出： 狮子 在森林上跑
            roadAnimal.run("摩托车");
           SeaAnimal seaAnimal = new SeaAnimal();
            //输出： 鲨鱼 在海洋里游
            seaAnimal.run("鲨鱼");
        }
    }

    // 陆地动物
    class RoadAnimal {
        public void run(String animal){
            System.out.println(animal + " 在公路上跑");
        }
    }

    //海洋动物
    class SeaAnimal {
        public void run(String animal){
            System.out.println(animal + " 在天上跑");
        }
    }

小结

核心思想：应该有且仅有一个原因引起类的变更

好处：类的复杂度降低、可读性提高、可维护性提高、扩展性提高、降低了变更引起的风险。

需注意：单一职责原则提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或类设计得是否优良，但是“职责”和“变化原因”都是不可以度量的，因项目和环境而异。

二、开闭原则

开闭原则的英文是 Open Closed Principle，缩写为 OCP。

开闭原则说的是：软件实体（模块、类、函数等等）应该对扩展是开放的，对修改是关闭的。

对扩展是开放的，意味着软件实体的行为是可扩展的，当需求变更的时候，可以对模块进行扩展，使其满足需求变更的要求。
对修改是关闭的，意味着当对软件实体进行扩展的时候，不需要改动当前的软件实体；不需要修改代码；对于已经完成的类文件不需要重新编辑；对于已经编译打包好的模块，不需要再重新编译。

两者结合起来表述为：添加一个新的功能应该是，在已有代码基础上扩展代码（新增模块、类、方法等），而非修改已有代码（修改模块、类、方法等）。

最简单的就是利用抽象类，将方法定义为抽象方法，然后在后代中重写方法，来进行单继承多实现。

示例：员工回家乘坐的交通方式

public abstract class Tools {
    /**
     * 抽象方法型行驶
     */
    public abstract void run();

}

package com.oop.day10;

public class Bike extends Tools {
    @Override
    public void run(){
        System.out.println("下班的人努力蹬三蹦子回家");
    }
}

package com.oop.day10;

public class Bus extends Tools{
    @Override
    public void run(){
        System.out.println("下班的人挤公交车回家");
    }
}

package com.oop.day10;
/**
 * @authorDesc 诸神在上，佑我程序，玄功护体，BUG皆去！
 * @author 
 * @date 2022-11-04 10:34:34
 * @version 1.0.0
 * @description 员工类
 */
public class Employee {
    private String name;

    public Employee() {
    }

    public Employee(String name) {
        this.name = name;
    }
    /**
     * 乘坐交通工具回家
     */
    public void goHome(Tools tools){
        System.out.println(this.name + "准备回家");
        tools.run();
    }
}

package com.oop.day10;

public class Test {
    public static void main(String[] args) {
        Employee emp1 = new Employee("马云");
        Employee emp2 = new Employee("马化腾");

        Tools tools1 = new Bike();
        Tools tools2 = new Bus();

        emp1.goHome(tools1);
        emp2.goHome(tools2);
    }
}

小结

核心思想：尽量通过扩展软件实体来解决需求变化，而不是通过修改已有的代码来完成变化。例如就同过抽象类来解决这个问题

通俗来讲：一个软件产品在生命周期内，都会发生变化，既然变化是一个既定的事实，我们就应该在设计的时候尽量适应这些变化，以提高项目的稳定性和灵活性。

三.接口隔离原则

什么是接口隔离原则

接口对于Java开发者来说都不陌生，它几乎存在于每一个Java程序中，是抽象的代名词。在讲接口隔离原则之前，先说说接口，接口分为以下两种：

实例接口（Object Interface)）
在 Java 中声明一个类，然后用 new 关键字产生一个实例，是对一个类型的事物的描述，这就是一种接口。或许我们乍一看会有点懵，怎么和我们原来学习的接口不一样呢，其实我们这样想，我们都知道，在 Java 中有一个 Class 类，表示正在运行的类和接口，换句话说每一个正在运行时的类或接口都是 Class 类的对象，这是一种向上的抽象。接口是一种更为抽象的定义，类是一类相同事物的描述集合，那为什么不可以抽象为一个接口呢？
类接口（Class Interface）
这就是我们经常使用的用 interface 定义的接口

这里插一句，接口隔离原则中所说的接口并不是狭意的在 Java 中用 interface 定义的接口，而是一种更为宽泛的概念，可以是接口，抽象类或者实体类。

接口隔离原则分析

接口隔离原则是指使用多个专门的接口，而不使用单一的总接口。每一个接口应该承担一种相对独立角色，不多不少，不干不该干的事，该干的事都要干。

1.一个接口就只代表一个角色，每个角色都有它特定的一个接口，此时这个原则可以叫做“角色隔离原则”。

2.接口仅仅提供客户端需要的行为，即所需的方法，客户端不需要的行为则隐藏起来，应当为客户端提供尽可能小的单独的接口，而不要提供大的总接口

3.使用接口隔离原则拆分接口时，首先必须满足单一职责原则，将一组相关的操作定义在一个接口中，且在满足高内聚的前提下，接口中的方法越少越好。

4.可以在进行系统设计时采用定制服务的方式，即为不同的客户端提供宽窄不同的接口，只提供用户需要的行为，而隐藏用户不需要的行为。

一旦一个接口太大，则需要将它，分割成一些更细小的接口，使用该接口的客户端需知道与之相关的方法即可。

设计存在问题：接口承担了太多职责

导致该接口的实现类很庞大，实现类中都需要实现接口所有方法，灵活性较差，如果出现大量的空方法，将导致系统中产生大量的无用代码，影响代码质量；

由于客户端针对大接口编程，将在一定程度上破坏程序的封装性，客户端看到了不应该看到的方法，没有为客户端定制接口。

因此需要按照接口隔离原则和单一职责原则进行重构。将其中的一些方法封装在不同的小的接口中，确保每一个接口使用起来都较为方便，并都承担某一单一角色，每个接口中只包含一个客户端（如模块和类）所需的方法即可。

优化后：

四.里氏替换原则

*里氏替换原则：**所有引用基类（父类）的地方必须能透明地使用其子类的对象。也就是说子类可以扩展父类的功能，但不能改变父类原有功能。

透明使用的关键就是，子类不能改变父类原有功能。

里氏替换原则由 Barbara Liskov 提出，这个原则很明显，Java 的多态或者 C++ 的虚函数本身就允许把指向基类的指针或引用，在调用其方法或函数的时候，调用实际类型的方法或函数。

里氏替换原则的内容可以描述为： “派生类（子类）对象可以在程式中代替其基类（超类）对象。”

继承

优点

提高代码的重用性，子类拥有父类的方法和属性。
提高代码的可扩展性，子类可形似于父类，但异于父类，保留自我的特性。

缺点（侵入性、不够灵活、高耦合）

继承是侵入性的，只要继承就必须拥有父类的所有方法和属性，在一定程度上约束了子类，降低了代码的灵活性。
增加了耦合，当父类的常量、变量或者方法被修改了，需要考虑子类的修改，所以一旦父类有了变动，很可能会造成非常糟糕的结果，要重构大量的代码。

为什么需要里氏替换原则

任何基类可以出现的地方，子类一定可以出现。里氏替换原则是继承复用的基石，只有当衍生类可以替换基类，软件单位的功能不受到影响时，即基类随便怎么改动子类都不受此影响，那么基类才能真正被复用。

因为继承带来的侵入性，增加了耦合性，也降低了代码灵活性，父类修改代码，子类也会受到影响，此时就需要里氏替换原则。

我们来看一个简单的例子：Circle 和 Square 继承了基类 Shape，然后在应用的方法中，根据输入 Shape 对象类型进行判断，根据对象类型选择不同的绘图函数将图形画出来。

void drawShape(Shape shape) {

    if (shape.type == Shape.Circle ) {
        drawCircle((Circle) shape);
    } else if (shape.type == Shape.Square) {
        drawSquare((Square) shape);
    } else {
        ……
    }
}

这种写法的代码既常见又糟糕，它同时违反了开闭原则和里氏替换原则。

首先看到这样的 if/else 代码，就可以判断违反了（我们刚刚在上个部分讲过的）开闭原则：当增加新的 Shape 类型的时候，必须修改这个方法，增加 else if 代码。
其次也因为同样的原因违反了里氏替换原则：当增加新的 Shape 类型的时候，如果没有修改这个方法，没有增加 else if 代码，那么这个新类型就无法替换基类 Shape。

要解决这个问题其实也很简单，只需要在基类 Shape 中定义 draw 方法，所有 Shape 的子类，Circle、Square 都实现这个方法就可以了：

public abstract Shape{
  public abstract void draw();
}

上面那段 drawShape() 代码也就可以变得更简单：

void drawShape(Shape shape) {
  shape.draw();
}

注意事项

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

小结

核心思想：在使用基类的的地方可以任意使用其子类，能保证子类完美替换基类。

通俗来讲：只要父类能出现的地方子类就能出现。反之，父类则未必能胜任。

好处：增强程序的健壮性，即使增加了子类，原有的子类还可以继续运行。

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

五.依赖倒置原则

依赖倒置原则的英文是 Dependency Inversion Principle，缩写为 DIP。依赖倒置原则说的是：高层模块不依赖低层模块，它们共同依赖同一个抽象，这个抽象接口通常是由高层模块定义，低层模块实现。同时抽象不要依赖具体实现细节，具体实现细节依赖抽象。高层模块就是调用端，低层模块就是具体实现类，抽象就是指接口或抽象类，细节就是实现类。

依赖倒置原则：

高层模块不应该依赖底层模块，二者都应该依赖其抽象。（高层理解为吃动作，底层理解为面包等具体食物）
抽象不应该依赖细节，细节应该依赖抽象。
依赖倒置的中心思想就是面向接口编程。

在继承时要遵循里氏替换原则。

错误示例：

class DependencyInversionTest {
    public static void main(String[] args) {
        Person person = new Person();
        person.receive(new Email());
    }
}

//电子邮箱类
class Email{
    public String getInfo(){
        return "获得电子邮件信息";
    }
}

//完成Person接受消息的功能
//缺点：如果要接受消息的对象是 微信类、短信类，就得增加相应的方法。
class Person{
    public void receive(Email email){
        System.out.println(email.getInfo());
    }
}
————————————————
版权声明：本文为优快云博主「做不秃头的程序员」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.youkuaiyun.com/weixin_41804870/article/details/109132932

解决示例：

引入一个抽象的接口IReceiver，表示接收者，这样Person类就只与接口发送依赖

class DependencyInversionTest {
    public static void main(String[] args) {
        Person person = new Person();
        person.receive(new Email());
        person.receive(new Wechat());
    }
}

interface IReceiver{
    String getInfo();
}

//电子邮箱类
class Email implements IReceiver{
    public String getInfo(){
        return "获得电子邮件信息";
    }
}

//微信类
class Wechat implements IReceiver{
    @Override
    public String getInfo() {
        return "获得微信信息";
    }
}

//完成Person接受消息的功能
class Person{
    //这样就不需要每添加一个消息对象就写相应的方法
    public void receive(IReceiver receiver){
        System.out.println(receiver.getInfo());
    }
}
————————————————
版权声明：本文为优快云博主「做不秃头的程序员」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.youkuaiyun.com/weixin_41804870/article/details/109132932

上面的示例是基于接口实现的，下面的示例是基于构造函数来实现的：

class DependencyInversionTest {
    public static void main(String[] args) {
        Person person = new Person(new Email());
        person.receive();
        person = new Person(new Wechat());
        person.receive();
    }
}

interface IReceiver{
    String getInfo();
}

//电子邮箱类
class Email implements IReceiver{
    public String getInfo(){
        return "获得电子邮件信息";
    }
}

//微信类
class Wechat implements IReceiver{
    @Override
    public String getInfo() {
        return "获得微信信息";
    }
}

//完成Person接受消息的功能
class Person{
    private IReceiver iReceiver;

    public Person(IReceiver iReceiver) {
        this.iReceiver = iReceiver;
    }

    public void receive(){
        System.out.println(iReceiver.getInfo());
    }
}
————————————————
版权声明：本文为优快云博主「做不秃头的程序员」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.youkuaiyun.com/weixin_41804870/article/details/109132932

下面的示例是基于setter方法来实现：

class DependencyInversionTest {
    public static void main(String[] args) {
        Person person = new Person();
        person.setiReceiver(new Email());
        person.receive();
        person.setiReceiver(new Wechat());
        person.receive();
    }
}

interface IReceiver{
    String getInfo();
}

//电子邮箱类
class Email implements IReceiver{
    public String getInfo(){
        return "获得电子邮件信息";
    }
}

//微信类
class Wechat implements IReceiver{
    @Override
    public String getInfo() {
        return "获得微信信息";
    }
}

//完成Person接受消息的功能
class Person{
    private IReceiver iReceiver;

    public void setiReceiver(IReceiver iReceiver) {
        this.iReceiver = iReceiver;
    }

    public void receive(){
        System.out.println(iReceiver.getInfo());
    }
}
————————————————
版权声明：本文为优快云博主「做不秃头的程序员」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.youkuaiyun.com/weixin_41804870/article/details/109132932