SRP: 单一职责如果有多于一个的原因修改类的实现,则视为违反单一职责规范.问题是我们怎样未卜先知会有一些什么需求变化呢 如果将类分离为两个,那么如果需要对它们进行同步操作时,把实现放哪里呢我想,设计模式的一个弊端就是让程序员不自觉的忽略(或弱化)了逻辑实体(类实例)之间的同步控制, 或者说增加了复杂度,以至于难于控制. 单一职责的极端是没有类的抽象,没有分组,没有归类. 这显然是不对的. 因此单一职责要适可而止, 如何适可而止? 没有标准答案! 这是一个中庸的原则.OCP: 开放-封闭原则允许通过增加新代码,不允许修改现有旧代码满足新需求. 这个原则太棒了. 这对于开发和部署太友好了. 当然满足这个原则的前提是能够抽象出不变的需求, 分离出可能变化的功能. 这样新功能就不会改变原有不变的逻辑,只增加新代码就可以了. 但是如果新功能就是要原来我们认为不变那部分需求我们该怎么办? 越抽象的逻辑距离实际需求越远, 反之则越近. 我们抽象到什么程度为止呢? 这又是一个中庸的原则.OCP背后的主要原则是抽象和多态.LSP: 里氏替换原则子类可以作为基类使用.当作为基类使用时,其行为不能违反基类的约束,如果其行为出现异常,则视为违反李氏替换原则.当然,我们不能期待应该在运行期决定的行为在编译期就能决定.(不能将虚函数替换为普通函数来提升效率, 虚函数本就是运行期才发挥作用的). 这是一种极端的行为, 是不计后果的行为.子类行为应该限定在基类限定的范围内, 如果子类违反基类的约束,则这种继承关系就是错误的.问题是我们怎么才能辨识出这种问题. 用数学的说法即子类应该是基类的子集,这个子集指行为,而不是简单说的属性(长方形的长变化时,宽不能因之变化,而正方形的长宽同时变化,基类的行为准则被子类放宽了)后面这段说明点出了继承的本质.
DIP: 依赖倒置原则
高层模块依赖低层模块,低层模块修改也会引起高层模块修改.这话听起来没错, 但反过来说低层依赖高层模块不也是一样吗? 只要二者相互依赖, 则谁也不能置身事外. 因此,关键的问题是双方解耦.
我们要界定双方的职责. 一般来说高层模块负责业务逻辑, 低层提供实现的机制.记住是机制而不是策略. 这里的机制是指抽象的机制而不是具体的某种实现. 这又是抽象的接口. 其实,只要低层不是三天两变, 依赖具体的低层也不是什么问题.
这里强调大多数类是不稳定的, 高层不应该依赖这些类. 言外之意, 这些易变的类竟然是低层类. 而不是代表着具体需求的高层类. 我很奇怪, 为什么低层类比高层类还易变吗? 这就好比盖房的砖一天三变,搞得工人们整天拆房重建! 怎么可能呢?
因此,这里的低层类,不是真正的低层,它们至少是代表了业务逻辑的准高层. 可以得出结论了, 这里是业务逻辑变化引起业务逻辑代码修改. 我们还是在试图抽象业务逻辑,这个完全靠猜(夸张了), 当不得真的!
另: 过程化程序设计出来的应用也许是策略依赖细节的.但用过程化语言设计出来的应用未必.
ISP: 接口隔离原则
不要暴露不必要的接口给客户,减少不必要的耦合.可使用委托或者多重继承来实现这一点.
阅读(1737) | 评论(0) | 转发(0) |
