Liskov替换原则与继承

如果一件事情你不能用自己的语言说清楚，那只能说你没有真正的理解它。“只可意会不可言传”在科学领域应该只是一种假象。

－－－－废话结束－－－－

　　 一直以来都认为自己搞清楚了何时用继承，何时用聚合，也清楚了所谓的Liskov替换原则的意义。直到今天看完了“高效程序员的十个习惯”以后才明白，才认识到自己以前的理解是

混沌含糊的。

      何时用继承呢？大部分情况我们仅仅为了利用另一个已存在的类的功能而继承，或者几个类有功能近似，或者代码重复，就提取个公用类，然后再继承之。长期以来，我都是这样的理解
。如果从实现上来说，这样是没有问题的，复用了代码，减少了重复。但如果用Liskov原则来审查设计就会发现，这样的实现其实是很欠妥的。是滥用继承的一种。下面我们具体分析。

      Liskov原则要求我们，“任何能用基类的地方都应该可以无差别的使用其继承类替换”。“滥用的继承”模式也可以从实现层面遵循此规则，因为它也是继承。但由于脱离了继承的本意，这样的实现最终会得到差强人意的结果。比如基类中A方法是要求”站力“，而继承B却实现成了”坐下“，从语法和实现上都没有问题，但却违背了设计继承的本意。这也是滥用继承也不会被有效察觉的原因：它不会主动报错，错误在潜台词里。

    继承，应该”不要求更多，不承诺更少“，也就是语意上的一致，而不仅仅是方法签名，只有IS－A的情况才可以使用继承。

    类似上面所说的这些”被滥用的继承“，最好的方式就是改造成聚合实现。虽然可能稍微麻烦一点点，但这满足设计的基本原则。

    通过对Liskov的理解，让设计更清晰，遵从对象本意设计，而不是语法与技巧。