里氏代换原则_接口隔离原则_java开闭原则(10)

我们常见这样的代码，至少我以前的Java和php项目中就出现过。比如有一个网页，要实现对于客户资料的查看、增加、修改、删除功能，一般Server端对应的处理类中都有这么一段：

if(action.Equals(“add”)){

//do add action

}

else if(action.Equals(“view”)){

//do view action

}

else if(action.Equals(“delete”)){

//do delete action

}

else if(action.Equals(“modify”)){

//do modify action

}

大家都很熟悉吧，其实这是违背里氏代换原则的，结果就是可维护性和可扩展性会变差。有人说：我这么用，效果好像不错，干嘛讲究那么多呢，实现需求是第一位的。另外，这种写法看起来很很直观的，有利于维护。其实，每个人所处的环境不同，对具体问题的理解不同，难免局限在自己的领域内思考问题。对于这个说法，我觉得应该这么解释：作为一个设计原则，是人们经过很多的项目实践，最终提炼出来的指导性的内容。如果对于你的项目来讲，显著增加了工作量和复杂度，那我觉得适度的违反并不为过。做任何事情都是个度的问题，过犹不及都不好。在大中型的项目中，是一定要讲究软件工程的思想，讲究规范和流程的，否则人员协作和后期维护将会是非常困难的。对于小型的项目可能相应的要简化很多，可能取决于时间、资源、商业等各种因素，但是多从软件工程的角度去思考问题，对于系统的健壮性、可维护性等性能指标的提高是非常有益的。像生命周期只有一个月的系统，你还去考虑一大堆原则，除非脑袋被驴踢了。

实现开闭原则的关键步骤是抽象化，基类与子类之间的继承关系就是一种抽象化的体现。因此，里氏代换原则是实现抽象化的一种规范。违反里氏代换原则意味着违反了开闭原则，反之未必。里氏代换原则是使代码符合开闭原则的一个重要保证。

通过里氏代换原则给我们带来了什么样的启示？

类的继承原则：如果一个继承类的对象可能会在基类出现的地方出现运行错误，则该子类不应该从该基类继承，或者说，应该重新设计它们之间的关系。

动作正确性保证：符合里氏代换原则的类扩展不会给已有的系统引入新的错误。

2.3 最佳实践在项目中，采用里氏替换原则时，尽量避免子类的“个性”，一旦子类有“个性”，这个子类和父类之间的关系就很难调和了，把子类当做父类使用，子类的“个性”被抹杀——委屈了点；把子类单独作为一个业务来使用，则会让代码间的耦合关系变得扑朔迷离——缺乏类替换的标准。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-21726-10.html