关于解耦的研究(三)设计模式与解耦

前言

设计模式对于任何一个软件开发人员来说，我想都不会陌生，这部经典巨著在软件开发人员心中的地位也是神圣般的存在。

虽然很多学校在大学阶段、研究生阶段便加入来此类课程的教学，但能掌握其精髓，融会贯通的人少之又少。

笔者身边不少资深软件开发人员都曾说，设计模式是需要多年开发经验的积累的，只有当你编写了很多程序在回过头来读这本书时，才能感受到其中的精髓，理解其中的奥义！

本文要点

本文的目的不是讲解设计模式，而是已解耦为目的，吸取研究设计模式中关于解耦相关的经验。文中很多内容也是笔者通过看书及他人文章总结的，感谢前人宝贵的经验以及乐于奉献的精神！
通过本篇文章，你将要了解到：

1.设计模式六大原则与解耦的关系
2.常用与解耦的设计模式之组合模式；
3.常用与解耦的设计模式之事件队列；
4.常用与解耦的设计模式之服务定位器；

六大原则与解耦的关系

单一职责原则

单一职责原则很简单，它就像内聚度中的功能内聚，其聚合度最高，当然耦合度也会最低

里氏替换原则

子类由于继承类父类的属性和方法，自然与父类产生了一定程度的耦合，增加了耦合度，同时其他模块与子类的耦合也将转移至父类，一定程度上可以把耦合集中

依赖倒置原则

依赖抽象，依赖接口编程，和耦合的关系似乎不大

接口隔离原则

类不应该依赖它不需要的接口，和耦合的关系似乎也不大

迪米特法则

尽量少暴露实现细节，其他模块对此模块所需细节了解的越少，模块间的耦合度越低

开闭原则

对扩展开放，对修改关闭。当耦合度很低的时候，发生变化，自然可以极大减少修改

总结一下

1.遵守单一职责、迪米特法则可以有效降低耦合。
2.适当运用里氏替换原则，控制父子类间的耦合，或把耦合集中给父类。
3.开闭原则将受益于耦合度的降低。
4.依赖倒置原则和接口隔离原则让我很纠结，对耦合度影响似乎不大，仅能一
定程度提升内聚度，更关乎与接口的设计。

接下来谈下常用于解耦的设计模式：

组合模式

在oop的开发中，继承是必不可少的，随着功能模块复杂度的提高，继承的结构也会越来越庞大，越来越复杂，子类与父类耦合度极具增高，然而复杂的继承体系中，往往存在着很多独立，相互并不关联的模块，这样的混合造成了很多不必要的耦合性，为了解决此类问题，组合模式应运而生。

组合模式，主要是用来描述整体与部分之间关系。设计模式中的定义为将对象组合成树形结构以表示“部分-整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致性。

组合模式详解https://www.runoob.com/design...

案例实战：待补充

事件队列模式

日常开发中，当某一个一块状态发生变化时，经常需要通知其他模块，通常的做法是在触发模块增加一个函数，将需要通知的模块的逻辑写入其中，已达到通知的效果。然而这样就让变化的触发模块和变化后要处理的模块产生了耦合。当接受变化的处理模块变动时，或者触发模块变动时，必须修改各模块逻辑，违反了开闭原则。

建立一个事件队列模块来维护所有的事件，在模块发生变化时，触发模块抛出对应事件给事件队列，而变化接收者仅需要在事件队列中注册想要接收的事件，这就是事件队列模式的简单介绍。通过事件队列模式变化的触发者和变化的接收者就可以完全解除耦合，极大降低耦合度。

事件队列模式详解https://blog.csdn.net/u010223...

案例实战：待补充

服务定位器模式

日常开发中很难避免很多全局的系统如音效播放，日志系统、外部的sdk等，这些系统可能会渗入我们开发的软件中的各个角落，产生大量耦合，而服务定位器则就可以有效降低这种情况产生的耦合。

创建一个服务定位器模块，用来提供一些全局必须的服务。全局的系统模块由原来的单例调用或静态直接调用，改为从服务定位器中获取，服务定位器返回的可以是接口或者基类、或者包含接口的空服务，这样服务使用者和服务器提供者之间的耦合将有效降低。也可以在服务定位器中方便的更换全局的服务提供者，带来更大的扩展性。

服务定位器模式详解https://www.runoob.com/design...

案例实战：待补充

以上均为本人拙见，之后也会不断精进及深入研究，本文将长期维护，不断优化。。。

欢迎各位大佬提供宝贵建议，助力完善！

上一篇关于解耦的研究(二)之基础解耦实践
下一篇 思考中