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

}

public static void main(String[] args) {

invoker();

}

}

代码运行后的结果如下所示：

子类被执行...

完蛋了吧？！子类在没有覆写父类的方法的前提下，子类方法被执行了，这会引起业务逻辑混乱，因为在实际应用中父类一般都是抽象类，子类是实现类，你传递一个这样的实现类就会“歪曲”了父类的意图，引起一堆意想不到的业务逻辑混乱，所以子类中方法的前置条件必须与超类中被覆盖的方法的前置条件相同或者更宽松。

覆盖或实现父类的方法时输出结果可以被缩小这是什么意思呢，父类的一个方法的返回值是一个类型T，子类的相同方法（重载或覆写）的返回值为S，那么里氏替换原则就要求S必须小于等于T，也就是说要么S和T是同一个类型，要么S是T的子类，为什么呢？分两种情况，如果是覆写，父类和子类的同名方法的输入参数是相同的，两个方法的范围值S小于等于T，这是覆写的要求，这才是重中之重，子类覆写父类的方法，天经地义。如果是重载，则要求方法的输入参数类型或数量不相同，在里氏替换原则要求下，就是子类的输入参数大于或等于父类的输入参数，也就是说你写的这个方法是不会被调用到的，参考上面讲的前置条件。

采用里氏替换原则的目的就是增强程序的健壮性，版本升级时也可以保持非常好的兼容性。即使增加子类，原有的子类还可以继续运行。在实际项目中，每个子类对应不同的业务含义，使用父类作为参数，传递不同的子类完成不同的业务逻辑，非常完美！

架构师之路(7)---里氏代换原则 4.1 什么是里氏代换原则

里氏代换原则是由麻省理工学院（MIT）计算机科学实验室的Liskov女士，在1987年的OOPSLA大会上发表的一篇文章《DataAbstraction andHierarchy》里面提出来的，主要阐述了有关继承的一些原则，也就是什么时候应该使用继承，什么时候不应该使用继承，以及其中的蕴涵的原理。2002年，我们前面单一职责原则中提到的软件工程大师Robert C. Martin，出版了一本《Agile SoftwareDevelopment Principles Patterns andPractices》，在文中他把里氏代换原则最终简化为一句话：“Subtypes must be substitutable fortheir base types”。也就是，子类必须能够替换成它们的基类。

我们把里氏代换原则解释得更完整一些：在一个软件系统中，子类应该可以替换任何基类能够出现的地方，并且经过替换以后，代码还能正常工作。

4.2 第一个例子：正方形不是长方形

“正方形不是长方形”是一个理解里氏代换原则的最经典的例子。在数学领域里，正方形毫无疑问是长方形，它是一个长宽相等的长方形。所以，我们开发的一个与几何图形相关的软件系统中，让正方形继承自长方形是顺利成章的事情。现在，我们截取该系统的一个代码片段进行分析：

长方形类Rectangle:

class Rectangle {

double length;

double width;

public double getLength() { return length; }

public void setLength(double height) { this.length = length;}

public double getWidth() { return width; }

public void setWidth(double width) { this.width = width; }

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