本人不是这方面的专家，只能说是浅谈，由于最近在独立开发游戏引擎，因此对于设计方面有了更深的体会，于是便有了这篇文章。
下面举几点说明：
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，增加尽可能少的代码 来 提高图本身的复杂性（从而增加功能），依赖倒置可以认为属于这一点
最终都目的都是使得： 能力/代码复杂度 的比值 达到最高
