面向对象设计之魂（六大原则）

傷城~ 2022-03-17 12:09 325阅读 0赞

> \[版权申明\] 非商业目的注明出处可自由转载  
> 博文地址：https://blog.csdn.net/ShuSheng0007/article/details/87901626  
> 出自：shusheng007

### 文章目录 ###

*  前言
 *  六大原则
 *   *  1 单一职责（Single Responsibility Principle）
     *  2 开闭原则（Open Close Principle）
     *  3 里氏替换原则（Liskov Substitution Principle）
     *  4 依赖倒置原则（Dependence Inversion Principle）
     *  5 接口隔离原则（Interface Segregation Principle）
     *  6 迪米特原则（Law of Demeter 又名Least Knowledge Principle）
 *  总结

# 前言 #

常言道实践是需要理论来指导的，而理论又是需要实践来检验和修正的，理论和实践就这样相互促进，最后将一个领域推向新的高度。从面向对象编程的出现到现在好像已经有半个世纪了（于1950s第一次出现在MIT），所以这六大原则是在无数先辈的理论与实践中产生的。  
身为一名主要使用面向对象编程软件从业员（码农），这六大原则是必须要掌握的，它就是设计模式的理论，设计模式是它的实践。

# 六大原则 #

这六大原则应该成为你在日常开发中的理论指导，只要你或多或少的遵循这六大设计原则，那么写出的代码就不会太烂，慢慢的你会发现你竟然理解了那些吊炸天的设计模式意图及设计思路。

软件的面向对象开发一般提倡遵循**SOLID**原则，这个单词就是我们这里前5个原则的首字母缩写。

## 1 单一职责（Single Responsibility Principle） ##

这个原则顾名就可以思义，就是一个类应该只负责一个职责，术语叫：仅有一个引起其变化的原因。简单点说：一个类中应该是一组相关性很高的函数及数据的封装，个中含义请自行意会。看起来简单，但是做起来就难了，这可能是六大原则中最难以熟练掌握的一个原则了，它高度依赖程序员的自身素质及业务场景。

例如两个男性码农能为是否应该将一个函数写进某个类里面吵一天，最后谁也没有说服谁，最后他两**成了好基友**！

其实单一职责不仅在类中遵循，在方法中也应该遵循，下面是几个判断是否违反原则的参考：

*  一个方法中if else等条件语句特别多
 *  一个类中依赖了很多其他的类
 *  一个类根据外部出入的值执行不同的任务

## 2 开闭原则（Open Close Principle） ##

它是面向对象最重要的设计原则，由[Bertrand Meyer（勃兰特.梅耶）][Bertrand Meyer_.]在1988年出版的[《面向对象软件构造》][Link 1]。中提出的。  
![在这里插入图片描述][format_png]  
本尊照片，[图片来源][Bertrand Meyer_.]

定义如下

> 开闭原则(Open-Closed Principle, OCP)：一个软件实体应当对扩展开放，对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。

提倡一个类一旦开发完成，后续增加新的功能就不应该通过修改这个类来完成，而是通过继承，增加新的类。  
大家想必都听过软件需求不断变化的那个段子，在软件开发这个行当唯一不变的就是变化本身。那为什么应该对修改关闭呢，因为你一旦修改了某个类就有可能破坏系统原来的功能，就需要重新测试。其实我知道你们此刻在想什么，回忆一下自己的日常工作，有几个遵守了这个原则，都是需求来了就找到原来的类，进去改代码呗，\_。看看有指导原则尚且如此，没有的话就更加乱套了。

那么是不是就一定不能修改原来的类的，当然不是了，我们都是成年人了，要清楚的认识到，这个世界**不是非黑即白**的。当我们发现原来的类已经烂到家了，当然在有条件的情况下及时重构，避免系统加速腐败。

违反此原则的参考：

*  增加需求时总是需要不断修改对应的代码

## 3 里氏替换原则（Liskov Substitution Principle） ##

这个原则的的提出则可以是一位女性[Barbara Liskov][]，下图为她2010年的照片，现在应该还健在吧，其实计算机这个行当的从业人员比较幸福，我们的祖师爷基本都健在，不像一些其他行业，都死了不知道多少年了，显得很神秘。  
![在这里插入图片描述][format_png 1]  
定义如下：

> 里氏代换原则(Liskov Substitution Principle, LSP)：所有引用基类（父类）的地方必须能透明地使用其子类的对象。

简单点说，一个软件系统中所有用到一个类的地方都替换成其子类，系统应该仍然可以正常工作。这个原则依赖面向对象的继承特性和多态特性，这个原则我们有意无意中使用的就比较多了。因为一个优秀的程序员一定面向抽象（接口）编程的，如果你不是，说明你还有很大的进步空间。

例如我们有如下的代码，一个图形的基类`Shap`,以及它的两个子类`Rectangle` ，`Triangle`,安装里式替换原则，所有使用`Shape`的地方都可以安全的替换成其子类。

//基类
    public abstract class Shape {
        public abstract void draw();
    }
    //子类矩形
    public class Rectangle extends Shape {
        @Override
        public void draw() {
            System.out.println("绘制矩形");
        }
    }
    //子类三角形
    public class Triangle extends Shape {
        @Override
        public void draw() {
            System.out.println("绘制三角形");
        }
    }

写一个使用Shape类的函数

public static void main(String[] args) {
        //使用Shape的子类Triangle 的实例来替换Shape的实例，程序工作正常
        drawShape(new Triangle());
    }
    private static void drawShape(Shape shape){
        System.out.println("开始画图");
        shape.draw();
        System.out.println("结束画图");
    }

输出结果：

开始画图
    绘制三角形
    结束画图

如上代码所示：本来`drawShape()`函数需要一个`Shape`的实例，而我们却传给他一个其子类的实例，但是它正常工作了。我们使用`Shape`的子类`Triangle`的实例来替换`Shape`的实例，程序工作正常。这个原则也非常重要而常用，面向抽象编程。

违反此原则的参考：

*  代码中使用了`isinstance`之类的之类判定类型，然后强制转换后使用里面的方法。
 *  类里面存在接口或者其继承的抽象类的方法的空实现,类似下面这样的

@Override
        public void laiDaYiMa() {
            //老子不来大姨妈，所以方法置空，啥也不干!
        }

## 4 依赖倒置原则（Dependence Inversion Principle） ##

这个原则的提倡者正是大名鼎鼎的 [Robert C. Martin][]，人称**Bob大叔**，其应该是面向对象编程中最重要的原则了吧。  
![在这里插入图片描述][format_png 2]  
定义

> 依赖倒转原则(Dependency Inversion Principle, DIP)：抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。

关键点：

1.  高层模块不应该依赖低层模块，两者都应该依赖其抽象
2.  抽象不应该依赖细节
3.  细节应该依赖抽象

看到上面的介绍是不是已经懵逼了，反正我刚开始学习编程（半路大龄非科班出身）的时候是彻底懵逼的。因为这个概念人家是从软件设计的角度说的，我们应该将其对应到我们具体的实践当中去理解，例如**Java**领域

抽象：java中的抽象类或者接口 （如上面代码中的Shape 抽象类）  
细节：java中的具体实现类（如上面代码中的Rectangle 和Triangle 实体类）  
高层模块：java中的调用类（例如上面代码中`drawShape(Shape shape)`函数的类）  
低层模块：java中的实现类（细节）

依赖倒置又叫依赖倒转，关键在倒置上，啥叫倒置，那不倒置的时候是什么样的？如下面图所示

正常情况下：调用类（高层模块）应该依赖**具体实现类**（低层模块实现细节）

倒置后：高层模块与低层模块都依赖了实现类的**接口**（低层模块的细节抽象），底层模块的依赖箭头向上了，所以叫依赖倒置了。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NodVNoZW5nMDAwNw_size_16_color_FFFFFF_t_70_pic_center]

例如菜鸟程序员（牛翠花）会这么写代码

private static void drawRectangle (Rectangle rectangle){        
            rectangle.draw();
        }
        private static void drawTriangle  (Triangle triangle){        
            triangle.draw();
        }

而老鸟（王二狗）则会

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

那么菜鸟的代码会有什么问题呢，假设现在产品经理觉得矩形不好看，让牛翠花将矩形换成五角形，那么牛翠花就要同时修改调用类和增加一个绘制类，而王二狗的代码只需要增加一个五角形的绘制类，这就遵循了**开关闭原则**

所以我们要对接口编程，举几个具体的例子：声明方法参数的类型，实例变量的类型，方法的返回值类型，类型强制转换等等场景。

牛翠花的代码直接依赖了实现细节，而王二狗的代码依赖的是实现细节的抽象（依赖倒置了）。刚入门时候我们都是牛翠花，但是几年后有的人变成了王二狗，有的人仍然是牛翠花。。。

## 5 接口隔离原则（Interface Segregation Principle） ##

> 接口隔离原则(Interface Segregation Principle, ISP)：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。

其实这个原则是很容易理解的，就是让调用者依赖的接口尽可能的小。例如人类分男人和女人，男人和女人都要吃饭，但是只有女人每个月来大姨妈，那么如果你设计一个接口里面除了吃饭还有来大姨妈同时给男人和女人用就不合适了。

interface IHuman{
        void eat();
        void sleep();
        void laiDaYiMa();//来大姨妈
    }

这你让男人情何以堪，万一有个菜鸟程序员抽风了，直接给把来大姨妈的方法实现了，那后果就。。。

//男人类不需要接口中的laiDaYiMa方法
    class man implements IHuman{
        @Override
        public void eat() {        
        }
        @Override
        public void laiDaYiMa() {
            //老子不来大姨妈，所以方法置空，啥也不干!
        }
    }
    class woman implements IHuman{
        @Override
        public void eat() {        
        }
        @Override
        public void laiDaYiMa() {
            System.out.println("王二狗，给老娘倒一杯热水");
        }
    }

上面的例子就违反了接口隔离原则，正确的做法是申明两个接口，使接口保持最小

interface IHuman{
        void eat();
    }
    interface ISpecialForWoman{
        void laiDaYiMa();//来大姨妈
    }

男人只实现`IHuman`,女人实现`IHuman` 和`ISpecialForWoman`

class man implements IHuman{
        @Override
        public void eat() {
        }
    }
    class woman implements IHuman,ISpecialForWoman{
        @Override
        public void eat() {
        }
    
        @Override
        public void laiDaYiMa() {
            System.out.println("王二狗，给老娘倒一杯热水");
        }
    }

## 6 迪米特原则（Law of Demeter 又名Least Knowledge Principle） ##

迪米特法则来自于1987年美国东北大学(Northeastern University)一个名为“Demeter”的研究项目，又称最少知识原则(LeastKnowledge Principle, LKP)，其定义如下：

> 迪米特法则(Law of Demeter, LoD)：一个软件实体应当尽可能少地与其他实体发生相互作用。

一个类应该对自己需要调用的类知道得最少，类的内部如何实现、如何复杂都与调用者或者依赖者没关系，调用者或者依赖者只需要知道他需要的方法即可，其他的我一概不关心。

# 总结 #

以上六大原则全部是以构建灵活可扩展可维护的软件系统为目的的，所以说它的重要性是高于设计模式的，也应该是程序员时刻印在脑子里的，设计模式只是它的具体实践而已。

我将会逐步撰写一些简单易懂的设计模式相关的文章，对设计模式感兴趣的同学欢迎关注博主，带你装b带你飞

[Bertrand Meyer_.]: https://en.wikipedia.org/wiki/Bertrand_Meyer
[Link 1]: https://en.wikipedia.org/wiki/Object-Oriented_Software_Construction
[format_png]: /images/20220317/360a9df70c934d4eaee63ba783bd5e92.png
[Barbara Liskov]: https://en.wikipedia.org/wiki/Barbara_Liskov
[format_png 1]: /images/20220317/0f44b91661a24e51943c95464a982f9c.png
[Robert C. Martin]: https://en.wikipedia.org/wiki/Robert_C._Martin
[format_png 2]: /images/20220317/7a082173538246f880743b9beb76bda5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NodVNoZW5nMDAwNw_size_16_color_FFFFFF_t_70_pic_center]: /images/20220317/50ffc6adabb9406ca7cad96df01fb337.png