设计模式：设计原则 part1

Posted 2021-04-25 羣尔不群

This browser does not support music or audio playback. Please play it in WeChat or another browser.

0.前言

      在面向对象软件开发中，特别是在一些界面交互的设计上，我们尽量想一些方法方式，以提高软件的可维护性和可复用性，增加软件的可拓展性和灵活性。不过对于没有太多软件设计经验的新手菜鸟来说（比如我），去总结出类似方法无疑是难于上青天（除了天生就有非凡领悟能力的大神）。好在一些软件界的前辈们利用他们与代码厮杀留下的经验，总结出了一些能让我们把握住大方向的原则建议，可以大大提高我们软件的开发效率，节约软件的开发成本和维护成本。

       这里前人给我们大概总结了7个设计原则，分别是开闭原则、里氏替换原则、依赖倒转原则、单一职责原则、接口隔离原则、迪米特法则、合成复用原则。

       这些设计原则会分成两个部分来写，下面将对前4个设计原则进行简单介绍。

1.开闭原则

      开闭原则，又称开放-封闭原则，指的是软件实体（类、模块、函数等）可以扩展，但是不可以修改。也就是对于我们所写类或者函数来说，当应用需求发送变动时，我们可以在不修改本身代码的情况下，可以对其拓展功能，使其满足新需求。

      开闭原则是面向对象设计的核心所在，一般来说，开闭原则的目的是使软件实体拥有一定的适应性和灵活性的同时具备稳定性和延续性，其作用大致可分为三点：1、在变更代码时只需对变更部分（也就是拓展部分）进行测试即可；2、提高代码的可复用性（粒度小）；3、提高代码的可维护性。

      开闭原则一般可以通过“抽象约束、封装变化”来实现，即通过接口或者抽象类为软件实体定义一个相对稳定的抽象层，而将相同的可变因素封装在相同的具体实现类中。

      一点忠告：不要为了抽象而抽象，不要刻意去对所有类进行抽象，不要忘了我们的目的，我们仅需对程序里会出现频繁变化的部分进行抽象。

2.里氏替换原则

      里氏替换原则的大概意思是：子类可以扩展父类的功能，但不能改变父类原有的功能。熟悉继承关系的同学应该能想明白，这换句话说就是子类在继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法（非抽象的）。

      里氏替换原则是继承复用的基础，是对开闭原则的补充，其主要作用是：1、是实现开闭原则的重要方式之一；2、克服了继承中重写父类造成的可复用性变差的缺点；3、保证类的新增功能不会给原有的系统引入新的错误，降低了代码出错的可能性。

      父类一般会包含抽象方法和非抽象方法，其中抽象方法方法需要由子类去实现，而非抽象的方法子类不能去重写，如果重写了就会对整个继承体系造成破坏，违反了里氏替换原则。

      进一步说，如果程序违背了里氏原则，则子类对象在父类出现的地方会出现运行错误，这时需要重新设计两个类之间的关系。举个例子，在生物学中，一般会把企鹅划为鸟类，但是从类的继承关系上看，由于企鹅不能继承“鸟”会飞的功能，所以不能定义为“鸟”的子类，应该选择更高一级的类（比如动物类）作为父类。

      

3、依赖倒转原则

      依赖倒转原则的原始含义有两层：A.抽象不应该依赖细节，细节应该依赖抽象；B.高层模块不应该依赖低层模块，两者都应该依赖抽象。其核心思想为：要面向接口编程，不要面向实现编程。

      在软件设计中，细节具有多变性，而抽象层相对稳定（参考里氏替换原则），因此以抽象（接口或抽象类）为基础搭建起来的架构要比以实现的细节为基础的架构稳定得多。举个例子，像很多电脑主板都有的USB接口，在主板层面（可以理解为低层模块），不需要去考虑接进来的设备是什么；而接入设备（可以理解为高层模块），比如U盘，也不需要知道主板的电路是怎么设计的，两者只需遵循USB这个电气接口规范（抽象层），至于后面两者如何去做数据交互，则交给驱动去解决（细节层面）。

      依赖倒转原则的主要作用大概有：1、降低类间的耦合性；2、提高系统的稳定性；3、减少并行开发引起的风险；4、提高代码可读性和可维护性。

4、单一职责原则

      单一职责的含义是：就一个类而言，应该仅有一个引起它变化的原因。

      为什么一个类不能承担太多职责？原因大概有两点：1、一个职责的变化可能会削弱或者抑制这个类实现其他职责的能力；2、当client端需要该类的某一个职责时，不得不将其他不需要的职责包含进来，造成代码冗余。

      单一职责原则的核心是控制类的粒度大小，减低职责间的耦合性，提高类的内聚性，其作用大概有：1、降低类的复杂度；2、提高代码可读性；3、提高系统可维护性；4、降低因一个职责变更引起的风险。

      这里举个现实生活中的例子，比如我们常用的智能手机，集合了听歌、游戏、拍照等众多功能，是典型的一个多职责场景，虽然这样的设计方便了我们的日常生活，但是在专业领域上，例如摄影，一般专业的摄影师是不会使用手机去拍风景或者人物的。

      单一职责虽然简单，但是要实现起来，需要参与程序设计的人员有较强的应用场景的解构能力和重构经验，这些都非一朝一夕就能完成，需要长期的经验积累，想要熟悉设计模式亦是如此。