里氏替换原则_里氏替换原则详解_依赖倒转原则(4)

}

}

}

猫类Cat：

public class Cat extends Animal{

public Cat(String name){

super(name);

}

public void Mew(){

try{

System.out.println("Mew~~~ ");

}catch(Exception err){

System.out.println("An error occured!");

}

}

}

狗类Dog：

public class Dog extends Animal {

public Dog(String name) {

super(name);

}

public void Bark(){

try{

System.out.println("Bark~~~ ");

}catch(Exception err){

System.out.println("An error occured!");

}

}

}

测试类：TestAnimal

public class TestAnimal {

public void TestLSP(Animal animal){

if (animal instanceof Cat ){

Cat cat = (Cat)animal;

cat.printName();

cat.Mew();

}

if (animal instanceof Dog ){

Dog dog = (Dog)animal;

dog.printName();

dog.Bark();

}

}

}

象这种代码是明显不符合里氏代换原则的，它给使用者使用造成很大的麻烦，甚至无法使用，对于以后的维护和扩展带来巨大的隐患。实现开闭原则的关键步骤是抽象化，基类与子类之间的继承关系就是一种抽象化的体现。因此，里氏代换原则是实现抽象化的一种规范。违反里氏代换原则意味着违反了开闭原则，反之未必。里氏代换原则是使代码符合开闭原则的一个重要保证。

我们常见这样的代码，至少我以前的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

}

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

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

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

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

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

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