有时我们会听到人家讲：某某怎样做无所谓，只要别触碰到我的原则（底线）就行。当我看完大话设计模式总结六原则的时候，发现这句话就是设计模式的一个映射，设计原则就是设计模式模式的底线，是很有必要遵守的，下面就来详解“底线”：

　　首先，盗用郑浩师父一张图，原文链接：【大话一角】——六兄弟

单一职责原则

含义：就一个类而言，应该仅有一个引起他变化的原因，此原则的核心就是解耦和增强内聚性。

判断：如何判断职责是否应该分离呢？如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多余一个的职责，此时就需要考虑职责分离，将不同的职责封装到不同的类或模块中。

看图说话：感觉单一职责模式的前提是“总”，然后再“分”，即总分关系，用单一职责模式来形容这个原则突出了“分”，隐藏了“总”。

我的理解：拿一个公司的运作举例吧，每个部门负责自己分内工作，各司其职，即保持良好的内聚性，各个部门之间的工作不冲突，只会协调合作，最后汇总起来的工作结果就是预期的目标。

开放—封闭原则

含义：软件实体（类、模块、函数等）可以扩展，但是不可以修改。

看图说话：

　　上图所示关系若是想增加一个减法类，还需要动已经封装好的加法类，这样就违反了开闭原则，所以，我们就按照下图所示，用抽象来隔离以后发成的同类变化，这样的话，要是需要增加一个减法类，只需要增加运算类的子类就可以了~

我的理解：这个原则很像是“一国两制”，坚持一个中国的原则，大陆坚持原有的社会主义制度，而香港和澳门坚持原有的资本主义制度，可增加制度，但是不能修改制度。

依赖倒转原则

理解含义：高层模块和低层模块容易理解，每一个逻辑的实现都是由原子逻辑组成的，不可分割的原子逻辑就是低层模块，原子逻辑的再组装就是高层模块。那什么是抽象，什么又是细节呢？在Java语言中，抽象就是指接口或抽象类，两者都是不能直接被实例化的；细节就是实现类，实现接口或继承抽象类而产生的类就是细节，其特点就是可以直接被实例化，也就是可以加上一个关键字new产生一个对象。【更加精简的定义就是“面向接口编程”——OOD（Object-Oriented Design，面向对象设计）的精髓之一）

判定：程序中所有的依赖关系都是终止于抽象类或者接口，那就是面向对象的设计，反之就是过程化的设计。

“倒置”一词：到底什么是“倒置”呢？我们先说“正置”是什么意思，依赖正置就是类间的依赖是实实在在的实现类间的依赖，也就是面向实现编程，这也是正常人的思维方式，我要开奔驰车就依赖奔驰车，我要使用笔记本电脑就直接依赖笔记本电脑，而编写程序需要的是对现实世界的事物进行抽象，抽象的结果就是有了抽象类和接口，然后我们根据系统设计的需要产生了抽象间的依赖，代替了人们传统思维中的事物间的依赖，“倒置”就是从这里产生的。

优势：可以减少类间的耦合性，提高系统的稳定性，减少并行开发引起的风险，提高代码的可读性和可维护性。

反证法说明优势：若是不使用依赖倒置原则，所有的开发工作都是“单线程”的，甲做完，乙再做，然后是丙继续…，这在90年代“个人英雄主义”编程模式中还是比较适用的，一个人完成所有的代码工作，但在现在的大中型项目中已经是完全不能胜任了，一个项目是一个团队的协作结果，一个“英雄”再厉害也不可能了解所有的业务和所有的技术，要协作就要并行开发，要并行开发就要解决模块之间的项目依赖关系，那然后呢？依赖倒置原则就隆重出场了！

看图说话：

（1）建立两个接口：IDriver和ICar，分别定义了司机和汽车的各个职能，司机就是驾驶汽车，必须实现drive()方法；

（2）在IDriver中，通过传入ICar接口实现了抽象之间的依赖关系，Driver实现类也传入了ICar接口，至于到底是哪个型号的Car需要在高层模块中声明；

（3）在业务场景中，我们贯彻“抽象不应该依赖细节”，也就是我们认为抽象（ICar接口）不依赖BMW和Benz两个实现类（细节），因此我们在高层次的模块中应用都是抽象；

我的理解：依赖倒置原则在我看来就是让两个需要产生联系的个体间接联系，通过桥梁（接口）减少直接的依赖，就像是上图体现的人和车，人只要有了驾照，开什么车都可以，而不是有了驾照，只能开某一个牌子或是类型的车，那个驾照就像是接口，他能让人和任何车产生驾驶关系。所以，依赖倒置中的“倒置”一词在我看来理解为“弱化”更合适～

　　结束语：总结的过程中觉得大化设计模式越来越有意思了，总是能引起思维的发散，思维发散的时候，脑海中的故事比书中的还要精彩！

　　理解不当之处还望斧正～