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