2021-04-20 浅谈设计模式(一)

本人不是这方面的专家,只能说是浅谈,由于最近在独立开发游戏引擎,因此对于设计方面有了更深的体会,于是便有了这篇文章。

下面举几点说明:

1,依赖倒置:依赖倒置是设计模式六大原则之一,
官方说法为:上层不应该依赖下层,两者都应该依赖抽象

笔者实践之后发现这句话虽然说得有点抽象,其实际含义很简单

举例来说,一般的系统实现 都是高层模块直接依赖 低层模块,
这种实现已经算是不错的了,有明显的的分层体系,很多系统甚至没有分层体系,乱成一锅粥。

所谓分层体系,就是代码分为层,每个代码片段可以明确指明属于哪一层,高层可能依赖底层,而较低层绝对不会依赖高层。

分层体系的好处是避免循环依赖

笔者在实践中意识到,计算机科学的很多方面其实和数学中的图论有密切联系。

举例来说:
1,编译器的数据流分析涉及到图论,词法分析的状态机模型和语法树模型几乎就是图论的直接应用。
2,各种浏览器搜索算法和图论紧密相关
3,数据结构的层级表示表示可以看成树,为图的特列。
4,各种脚本文件的存储方式,甚至数据库的存储方式(B+Tree,图的特例)等
5,代码之间的模块的依赖关系,可以看成图
6,软件测试的复杂度分析比如圈复杂度的计算也是和图论有关。

据此,笔者认为计算机的很多方面可以通过图论作为指导依据来分析。

有一种理论是说,软件设计模式的根本意义就在于控制复杂度,这源于人脑的缓存有限。

个人理解,软件的一切架构和设计模式的最终意义在于:
用最低的复杂度实现最高的功能
这样我们得到了评判一个设计的标准:即是否降低了复杂度同时保留了功能。

但是一般的设计模式书籍并非源自 抽象演绎逻辑 ,而源自后验归纳,
这种写作方法导致了其理论性不够,

因此,c++的oop(面向对象编程)被许多著名人物所诟病,比如迪杰特斯拉,linus等曾经都批判过oop
个人也曾对oop范式包有疑问,主要在于认为这方面的书籍缺乏严谨的理论基础,对此迪杰特斯拉曾经有过类似的说法。

但是并不能完全否认oop的价值,作为一种广为普及的体系,必然有它的优点。

我们回到上文,为何要避免循环依赖,抛除去耦合性等说法不谈,
我们可以简单用图论语言来做不严谨的论证:
循环依赖导致图更复杂,从而使得图对应的代码更复杂,因此降低循环依赖就降低了图的复杂度,从而降低了代码的复杂度,而降低复杂度就是一切设计的最终目的。

我们再回到,设计模式的依赖倒置原则,

原始的依赖关系链是: A->B->C
A,B,C都为具体模块, 依赖倒置之后改为这样:
A->b B->c
B继承b C继承c
b,c为抽象基类或者接口 ,这样的好处是什么:

1,如果B或者C有变更,只要保持接口不变,不影响上层模块;
接口可以由上层模块制定,这更符合现实中的情况。

2,如果要在B所在层级增加一个 类 B'并且A同样需要支持对B'的一些操作,如果不依赖倒置,则需要重新实现一整套逻辑代码,
依赖倒置之后 只需要 让B'继承b并实现即可接口即可 ,降低了复杂度。

3,采用依赖倒置设计,所有的依赖关系终止于一个抽象类或接口,这样形成了面向接口编程体系,当我们需要增加一个新的类(可以看成图中一个节点),此时只需让这个类实现若干接口,就自动形成了,作用者作用于该类的 能力链(可以看成图中的边)这即是用最小的代价提高了最大的能力

从图论的角度来分析,有2种不同的思考路径:
1,降低图本身的复杂性,从而降低代码复杂性,但是由于本身功能体系更复杂的架构对应的图必然也更复杂,当这条路径优化到极致,就需要下面第二条优化路径

2,增加尽可能少的代码 来 提高图本身的复杂性(从而增加功能),依赖倒置可以认为属于这一点

最终都目的都是使得: 能力/代码复杂度 的比值 达到最高

你可能感兴趣的