SRP: 单一职责 @H_301_6@ 如果有多于一个的原因修改类的实现,则视为违反单一职责规范. 问题是我们怎样未卜先知会有一些什么需求变化呢 如果将类分离为两个,那么如果需要对它们进行同步操作时, 把实现放哪里呢 @H_301_6@我想,设计模式的一个弊端就是让程序员不自觉的忽略(或弱化) 了逻辑实体(类实例)之间的同步控制,或者说增加了复杂度,以至于难于控制. 单一职责的极端是没有类的抽象,没有分组,没有归类. 这显然是不对的. 因此单一职责要适可而止,如何适可而止? 没有标准答案! 这是一个中庸的原则. @H_301_6@ @H_301_6@OCP: 开放-封闭原则 @H_301_6@允许通过增加新代码,不允许修改现有旧代码满足新需求. 这个原则太棒了. 这对于开发和部署太友好了. 当然满足这个原则的前提是能够抽象出不变的需求,分离出可能变化的功能. 这样新功能就不会改变原有不变的逻辑,只增加新代码就可以了. 但是如果新功能就是要原来我们认为不变那部分需求我们该怎么办? 越抽象的逻辑距离实际需求越远,反之则越近. 我们抽象到什么程度为止呢? 这又是一个中庸的原则. @H_301_6@OCP背后的主要原则是抽象和多态. @H_301_6@LSP: 里氏替换原则 @H_301_6@子类可以作为基类使用.当作为基类使用时,sans-serif; font-size:13px">其行为不能违反基类的约束,如果其行为出现异常,sans-serif; font-size:13px">则视为违反李氏替换原则.当然,sans-serif; font-size:13px">我们不能期待应该在运行期决定的行为在编译期就能决定.( 不能将虚函数替换为普通函数来提升效率,虚函数本就是运行期才发挥作用的). 这是一种极端的行为,是不计后果的行为. @H_301_6@子类行为应该限定在基类限定的范围内,如果子类违反基类的约束,则这种继承关系就是错误的. 问题是我们怎么才能辨识出这种问题. 用数学的说法即子类应该是基类的子集,这个子集指行为,sans-serif; font-size:13px">而不是简单说的属性(长方形的长变化时,宽不能因之变化,sans-serif; font-size:13px">而正方形的长宽同时变化,基类的行为准则被子类放宽了) @H_301_6@后面这段说明点出了继承的本质.