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

时间 2020-04-20

标签关于研究设计模式繁體版

原文原文链接

前言

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

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

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

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

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

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

子类因为继承类父类的属性和方法，天然与父类产生了必定程度的耦合，增长了耦合度，同时其余模块与子类的耦合也将转移至父类，必定程度上能够把耦合集中函数

依赖抽象，依赖接口编程，和耦合的关系彷佛不大oop

类不该该依赖它不须要的接口，和耦合的关系彷佛也不大优化

尽可能少暴露实现细节，其余模块对此模块所需细节了解的越少，模块间的耦合度越低.net

对扩展开放，对修改关闭。当耦合度很低的时候，发生变化，天然能够极大减小修改设计

总结一下

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

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

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

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

案例实战：待补充

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

创建一个事件队列模块来维护全部的事件，在模块发生变化时，触发模块抛出对应事件给事件队列，而变化接收者仅须要在事件队列中注册想要接收的事件，这就是事件队列模式的简单介绍。经过事件队列模式变化的触发者和变化的接收者就能够彻底解除耦合，极大下降耦合度。

案例实战：待补充

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

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

案例实战：待补充

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

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