码迷,mamicode.com
首页 > 其他好文 > 详细

解耦设计手法小结

时间:2014-12-07 00:11:17      阅读:275      评论:0      收藏:0      [点我收藏+]

标签:设计

设计是一个平衡的产物,需要在各个约束条件下(组织目标,业务目标,开发流程,技术能力,学习及维护成本等)不断地进行演进。 我们虽然不提倡做大而全的设计,但会坚持进行基础性设计,以保证我们的设计一直在正确的方向上演进。

设计演进的过程既可以是自上而下的,也可以是自下而上的。


基本设计原则

业界普遍被接受的设计原则不再赘述。这里特别针对基于开源项目的软件,其总体主旋律将是:跟随,扩展,贡献,其中跟随将是一个基本能力,反观深度定制的方式会遭遇越来越多的尴尬。落实在设计上,其最核心的设计原则:隔离自有业务。相较于模块化的低耦合、高内聚的原则,这里的要求会更高。

先从模块上考虑应用的层次,依次考虑:

  • 应用层
  • 开源项目本身的定制或移植机制
  • 新增的接口层
  • 新增的适配层或业务层
  • 既有的接口层
  • 既有的实现


设计本身还要保证业务的完整性,以及对性能、系统开销、卡顿和稳定性的要求。

解耦的设计实践


以下为关于解耦的设计方法总结,以及应用要点便于在设计时评估。
解耦是隔离变化和降低复杂度的重要手段,这里以解耦代言隔离变化,其思想就是以分工协作代替全面控制,接口的定义大于业务逻辑的定义。
其思考路径是:分不分?如何分?

如何分是具体形式的问题,下面详述。分不分则取决于功能需求, 常见分离的需求有:

  • 功能强内聚
    . 这没什么好说的, 最常见的理由。
  • 功能的整合和转换
    . 就是为了整合某些功能或者达到某种切换的目的,向上提供一个更为标准统计的接口。内部可能会进行一些业务逻辑处理,数据、状态转换之类的操作。如编译器分出前后端也是这样的概念。
  • 降低复杂度


接口的定义至关重要,接口本身不能绑定业务约束或者流程。整体交互上是面向无状态的接口,而不是面向过程。过程的合理性,即业务流程则由不同的单元内部保障,再通过接口交互。

而向约束的编程也是在函数内进行约束的判断,间接达到带状态接口。

在手法上可以概括为从宏观到微观的四个层次:

  • 进程
    . 也可以是物理空间上的分离
  • 模块化/分层
  • 代码

    如下图:

bubuko.com,布布扣

进程

以分进程的方法来进行协作是Unix世界的传统,即KISS原则。Unix下有各式小工具,这些工具之间通过管道连结起来达到强大的功能。
另外以服务的方式隔离业务也很常见。如Windows中COM+的架构,甚至是HTTP Server等。
分进程的特点在于不同进程间的功能高度独立,并行处理的情况较多,服务提供者能够按需布署,存在一对多的情况,或有额外的安全性考虑。

而挑战在于性能、系统开销,需要熟悉IPC以及共享内存的知识。

分库

这是一个重要的模块化手法,主要是以动态库和脚本的形式, 甚至是独立的程序提供扩展。其核心思想是以插件的形式完成功能组装,以物理分离的形式提供出来。
插件本身实现一套标准的接口,包括:参数配置,接收输入,状态输出,数据输出等。
如Windows的核心驱动模块,Photoshop/GIMP中的图像处理功能,Matlab以及R语言中的函数库等等,不胜枚举。
以静态库形式提供出来的模块,更接近于代码级或者分层级别的体现,无法直接达到按需布署的能力。
分库要求各个独立库的接口层比较单一,特别适用于业务逻辑强内聚的场景。同时插件的功能将直接影响主程序的稳定性。

分层

就是将某一类功能的类和代码集中起来,向外提供特定接口或若干接口类,这个逻辑上的集合,就是层(layer)或者模块(module),也有叫unit或者API之类的。与分库、分进程本质区别就在于它是一个逻辑集合,优势在于可以更灵活的与不同模块交互,因为接口可以多样化(支持代码级的交互),这也同样是它的劣势,有时导致它形同虚设,丧失了解耦的能力。

所以分层成功与否,关键在于接口(含接口类)的定义和控制。

常见的一些手法,如MVC, 胶合层(glue),适配层(port),WebKit和Chrome中也有应用。

代码

这是一个最为微观,最为复杂的层次。但是到了这层,并不表示必然存在耦合问题。如果一些架构在设定上考虑到了扩展和适配的需求,在这个级别进行解耦反而最为自然。

WebKit的port方案


以Image类为例,它的一个函数与平台相关,于是类的实现被放在了三个文件中Image.cpp, ImageMac.mm和ImageWin.cpp中。Image.cpp中实现了公共的部分,而ImageMac.mm中实现了Mac OS版本,而ImageWin.cpp则实现了Windows版本。

bubuko.com,布布扣

另一种实现方式,如多媒体元素的播放控件。首先是MediaPlayer提供了一部分公共的逻辑,对于与平台相关实现的部分,定义了一个MediaPlayerPrivateInterface,各平台继承自这个接口实现各自的逻辑。

bubuko.com,布布扣


当我们解决了架构上的解耦后,在模块内部引入一定的耦合度就不是问题了。可供选择的方法就太多了。

Helper Class

Helper Class已经为一个类添加一个友类,执行一些差异化的业务。
Helper Class可以使用类似WebKit Port的机制为不同的系统提供不同的实现,也可以配合工厂模式,实现更为弹性的选择。
bubuko.com,布布扣

分散的逻辑判断就可以转为函数调用。
bubuko.com,布布扣

关于helper的使用一直是有争议,网上也有很多避免使用helper class的讨论。 主要论调在于认为helper class是过程化的产物,思考时是考虑的是流程上的逻辑补充。

转载请注明出处: http://blog.csdn.net/horkychen


参考:  优化解耦的设计思考

         自然而然的设计

         WebKit模块化分析

 Unix设计哲学

转载请注明出处: http://blog.csdn.net/horkychen

解耦设计手法小结

标签:设计

原文地址:http://blog.csdn.net/horkychen/article/details/41780553

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!