目录
设计模式之遵循原则
注：以下内容均参考《大话设计模式》。
1. 单一职责原则(SRP)
1.1 设计目的
我们在做编程的时候，会很自然的给一个类添加各种各样的功能，比如我们写一个窗体应用程序，一般都会生成一个Form这样的类，于是我们就把各种各样的代码，像商业运算的算法，像数据库访问的SQL语句都写入到该类中，这样意味无论任何需求要来，你都需要改变这个窗体类，这样维护麻烦，无法复用，缺乏灵活性。
所以我们在设计一个类时，要遵循单一职责，让类具备原子化属性。
1.2 定义
就一个类而言，应该仅有一个引起它变化的原因。
1.3 应用
设计俄罗斯方块：
- 分别设计3个窗体的Form类, WallForm(背景容器), NewShapeForm(新产生的形状)， ResultShapeForm(最终组合的形状)，输入参数，横纵坐标，和形状代码。
- 设计Operation类，用于产生随机的NewShape的输入参数，产生改变形状的code，挪移的输入横纵坐标，获取Form的当前位置，已经最后合并操作等属性。
2. 开放-封闭原则(OCP)
2.1 设计目的
在设计模式中，软件系统给架构更新，不破坏原有的软件内容去扩展新的内容，从而对旧版本软件兼容 。而不至于说，新的需求一来，就要把整个程序推倒重来。
2.2 定义
是指软件实体（类、模块、函数等）应该可以扩展，但是不可以修改。用人话就是，软件实体具有可扩展性，已经设计好的内容不用再去修改，这样就支持旧版本的兼容。（多扩展，少修改）
但无论模块是多么的封闭，都会存在一些无法对之封闭的变化。既然不可能完全封闭，设计人员就必须对于他设计的模块应该对哪种封闭做出选择。他必须先猜测出最有可能发生的变化种类。然后构造抽象来隔离那些变化。需求的变化很难预测，但我们可以在发生很小的变化时就采取行动。
在我们最初写代码是，假设变化不会发生。当变化发生时，我们就创建抽象来隔离以后发生的同类变化。
我们希望的是在开发工作展开不久就知可能发生的变化。查明可能发生的变化所灯带的时间越长，要创建正确的抽象就越困难。
！！！开发人员应该仅对程序中呈现出频繁变化的那些部分做出抽象。对于应用程序中每个部分都刻意地进行抽象同样不是一个好主意，拒绝不成熟的抽象和抽象本身一样重要。过犹不及。
2.3 应用
以计算器程序为例：
- 首先在一个类中设计了一个加法函数功能。
- 然后再添加一个减法的需求，此时就需要考虑重构，抽象一个运算类，加法和减法都是运算类的子类。
- 最后又追加了一个乘除的需求，此时只需要再分别添加乘法和除法的子类，就可以完成业务，而不用修改现有的代码。
3. 依赖倒转原则
3.1 设计目的
为了让对象强内聚，对象和对象之间松耦合。解决模块与指定模块的强耦合关系。比如，一厂家内存条插口只能给自己的定制的主板使用，因为主板和内存条是定制的接口，不是符合市面上标准接口，主板就无法再用其他厂家的内存条了。所以这个原则应运而生。定义一个大家都使用的接口。
3.2 定义
a) 高层模块不应该依赖低层模块。两个都应该依赖抽象。用人话就是高层模块使用低层模块也只是使用低层模块的接口或抽象类，这样当低层模块所代表的子类对象改变时，高层模块并不会受到影响。另外，高层模块也应是一个抽象的接口或抽象类。增加高层模块的复用性和灵活性。这里的高层模块和低层模块都是那些频繁使用的模块。
b) 原话解释是抽象不应该啊依赖于细节，细节应该依赖于抽象。说白了就是针对接口编程，而不是对实现编程，不管是大模块还是小模块。
3.3 应用
以设计建筑模块(欧式或中式)为例：
1. 抽象一个建筑模块Building, 派生子类EuropeanBuilding或ChinneseBuilding,也可以两个都派生。
2. 抽象一个内部房间模块Room, 派生子类EuropeanRoom或ChineseRoom，也可以都派生。
3. 为了在Building中灵活选择内部房间类型Room, 两个子类中都添加Art 属性,并赋予相应的中式还是欧式作为内部装修方式。
4. 这样，在使用建筑模块的时候，就可以灵活选择模式，即 “中式建筑+中式room，中式建筑+欧式Room， 欧式建筑+中式Room， 欧式建筑+欧式Room”。
4. 迪米特法则(LoD,最少知识原则)
4.1 设计目的
降低类之间的耦合
4.2 定义
如果两个类不必彼此直接发生通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以欧谈过第三者转发这个调用。
迪米特法则首先强调的前提是在类的结构设计上，每一个类都应该尽量降低成员的访问权限。其根本思想是强调了类之间的松耦合。类之间的耦合越弱，越有利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及。
4.3 应用
287
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
