面向对象六大基本原则的理解

Posted 2020-06-12

在学习设计模式的时候，总是被推荐先学习一下面向对象的六大原则，学习后果然受益匪浅。以下完全是我对六大基本原则的理解，和官网解释可能有出路，而且我更多是站在设计模式的角度，而不是面向对象的角度理解，如果有什么错误，敬亲谅解。

1.开闭原则

很多教程都把开闭原则作为这六大原则中最基本的原则，也就是说他是各个原则的核心。开闭原则指的是，一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。

至于这个具体怎么理解，我也看了很多教程，有些教程说当我们遇到新的需求，就需要我们对我们模块继承的形式进行扩展，而不是修改代码。这样的解释貌似有道理，但是如果真的这样做了，程序结构只会更加复杂，业务逻辑只会更不清晰，完全是一种作死的做法。当业务发生改变的时候，肯定是要修改代码的，不需要的东西留着只会让程序臃肿，让维护者搞不清什么是有用的代码，什么是已经过时的代码。我不太相信开闭原则的真谛是让我们走向这样一个死胡同。

对于开闭原则，我的理解是，我们在设计软件的时候，首先要搞清楚程序当中什么是未来可能变化的，什么是未来不会变化的。对于可能变化的东西，我们要提前给与可以对应的扩展接口。当然实际开发中，即便是我们认为这些不会变化的地方，未来还是可能变化的，这种变化就只能改代码了，但是这种修改仅仅只是改变个别细节，整体架构往往不会变化。而对于可能变化的地方，我们要给出可以足够扩展的空间，让其能够自由扩展，基本发生了重大的需求变更，整体架构也不会受影响。

例如：工厂模式中，我们将创建对象的过程封装了起来，这样创建对象对的过程中，创建的代码就和调用的代码尽可能地解除了耦合。创建过程可能是变化的，而调用过程往往是不变的。我们创建一个对象之后，需要为其初始化，设定一些配置，这个过程需要我们给出可以扩展的余地，而且要求扩展的时候不能影响调用部分，所以需要使用工厂模式，将可变的创建过程封装起来，供不变的调用模块。

这样说来，开闭原则的核心是解耦了？没错，我认为开闭原则讲的就是解构，但是他要求我们在设计的时候，重点要预判出什么地方是会发生变化的，并要为变化的地方留出余地。他强调的是对于可变部分进行解耦，使用扩展的方式而不是修改的方式应对变化，这样可以保证程序整体不会发生大的变化。

开闭原则对于开发框架、可以被复用的组件（如jar、dll、js插件等待）尤为重要，因为这些组件必须留出足够的空间去让调用者去扩展自己的业务。所以我们在开发这种组件的时候api才是最难设计的，因为我们设计的api必须能满足调用者对他的全部扩展，这样才能实现调用者在不修改组件代码的情况下实现自己的需求。

2.里氏替换原则

这个原则挺简单，讲的就使用接口的时候，我们必须确保子类能够替换父类所出现的任何地方。纯粹就字面的意思来讲，就是父类接口必须确保所有子类都可以实现需求，而不是某一个子类。

例如，java中HashMap和LinkedHashMap都是Map的子类。但是HashMap的顺序是随机的，而LinkedHashMap是固定的。当我们需要使用一个map，此map不需要要求key顺序可控的话，我们可以声明：

Map createMap(){
　　return new HashMap();
} 

但我们要求顺序可控是，如果是这样：

Map createMap(){
　　return new LinkedHashMap();
} 

上述代码就不太好了，因为HashMap也是Map的一个子类，但是他不能满足我们的需求，所以此处必须声明返回值类型为LinkedHashMap。例如我们在设计接口的方法的时候，如果调用者需要的是一个LinkedHashMap，我们就不能以HashMap类型做接口的声明。

当然里氏替换原则也可以从设计角度出发，他强调我们设计的时候需要确保父类定义了的时候，就应该覆盖到这个接口抽象出的业务的所有方法，而不需要他的子类再添加额外的扩展，同时各个子类也都该实现父类中的所有接口，只有这样才能保证我们设计出的东西是可扩展的。

开闭原则讲究扩展，里氏替换原则可以确保通过继承这种方式的扩展是可行的，否则就无法使用继承去扩展程序了。

例如：我们使用模板模式，做了一个类作为父类算法模板，一个子类继承了这个模板，并且顺利地完成了运行；但是另一个子类也继承了模板类，却无法运行，最终发现程序无法确保所有继承模板的子类可以替换父类，这就是个失败的模板模式。

从面相对象的角度来说，里氏替换原则是子类可以替代父类，但是从面相组件的角度看，其实是确保组件的api是完整的、不变的，子类和外界也是完全解耦的，只有这样我们开发出的扩展才能在不破坏原有框架的基础上运行。

3.依赖倒置原则

这个原则也是讲究解耦，他指的是让高层模块不要依赖低层模块。这个是个纯粹的面向接口，面向模块开发思路了，因为面向对象而言，各个对象自己的东西和外界是解耦的，因为封装特性把它们自己的属性都封装起来了，所以是不会和其他对象有耦合关系的（如c++的友元除外）；但是各个对象仍然是相互耦合的，最强的耦合就属于继承耦合了，对象组合起码还是轻耦合，继承是个高耦合呀。依赖倒置就是让各个对象耦合度降低，高层模块不能继承底层模块，需要底层的东西也是外界注入而不是自己创建得到；同时调用的时候也是使用接口调用，而不是依赖具体实现，并且因为是接口调用，具体实现模块可以被任意替换了。

这样做就可以降低各个模块的耦合，也可以确保里氏替换原则的实现。实现里氏替换原则有什么用？当然是可以方便扩展了。

456.职责单一原则、最小知道原则、接口隔离原则

这几个原则很像，就放到一起说吧。这几个类都是在强调解构（当然开闭原则、里氏替换原则、依赖倒置原则）。这几个原则基本都是强调解构，只是站的角度不一样，他们说的是一个类只负责一项职责，一个类对另一个类的依赖应该建立在最小的接口上，调用者不应该依赖它不需要的接口，一个对象应该对其他对象保持最少的了解。其实他们说的就是类和接口设计要尽量降低耦合的问题。

总结：和设计模式的关系

简单介绍了一下这几大基本原则，再说说我对于他们和设计模式的理解。我们在学习设计模式的时候，有没有想过为什么要学习这个，学习了设计模式有什么好处？我在工作中经常发现很多经验欠缺的程序员，为了学习设计模式而学习设计模式，为了使用设计模式而使用设计模式，而有经验的程序员则不会这样。其实程序员开发的每一个程序都是从需求出发的，只有搞清楚我们一个项目的根本需求才有使用设计模式的意义。

六大原则中，最重要的肯定就是开闭原则了，我对开闭原则的理解是，你无须在每个细节上都要做到对扩展开放，对修改关闭，而是应该为了面对扩展而扩展。当有这种需求的时候，例如一个项目业务、算法可能会有重大的变化，或者本身开发的就是一个组件，这是才需要扩展，而扩展的时候才应该使用设计模式来实现这种需求，也就是说使用设计模式和我们平时开发一样，都是满足需求。

使用了设计模式不一定能真正地提高代码的结构和可维护性，所以有经验的程序员会按需求而使用设计模式。六大基本原则可以更好地帮我们如何分析，这样才能确定是否使用设计模式。事实上设计模式的使用上我建议无招胜有招，满足项目的额外需求（例如利于扩展、可复用、高可维护性）都是好招，无需管他是什么设计模式。