六大设计原则之“里氏替换原则”

通俗地讲，只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。但是，反过来就不行了，有子类出现的地方，父类未必应能适应。

里氏替换原则为良好的继承定义了一个规范，一句简单的定义包括了四层含义：1、子类必须完全实现父类的方法

父类：AbstractGun

Java代码

Java代码

子类之步枪：Rifle

Java代码

Java代码

子类之机枪：MachineGun

Java代码

Java代码

士兵类：Soldier Java代码

Java代码

场景类：

Java代码

Java代码

已经违背原则。

常见畸型继承举例：

接上面的应用举例，如果我们要把一把玩具枪给三毛，那么新增类：ToyGun Java代码

Java代码

父类的方法，或者父类的某些方法在子类中发生畸变，则建议断开父子继承关系，采用依赖、聚集、组合等关系代替继承。

所以如上情况，建议方案是：ToyGun脱离继承，建立一个独立的父类(如AbstractToy)，为了实现代码复用，可以与AbstractGun建立关联委托关系。例如，可以在AbstractToy中声明将声音、形状都委托给AbstractGun处理，玩具枪嘛，形状和声音都要和真枪一样，然后两个基类下的子类自由延民

2、子类应避免自己的个性

子类是可以有自己的方法和属性，但在LSP原则里，可以正着用不能反过来用。在子类出现的地方，父类未必就可以胜任。

比如，现在又有一把新枪AUG，它是狙击枪也是步枪的一种：

Java代码

Java代码

而其它的子类却都没有。那么要真正使用zoomOut方法，则必须直接调用AUG

子类，不能使用抽像类或接口，则违背了上述第一个标红注意点。比如，要让

Soldier类使用AUG的个性方法zoomOut，则不能使用：AbstractGun _gun为_gun 属性的类型，则需直接调用AUG：AUG _gun。

3.覆盖或实现父类的方法时输入参数应相同或更宽松

举例，父类：

Java代码

Java代码

子类：

Java代码

Java代码

场景类：

Java代码

Java代码

此处是重载Overload，而不是覆写Override。

子类的输入参数类型的范围扩大了，将父类中的HashMap扩大到Map，子类代替父类传递到调用者中，子类永远不会被执行，这是正确的。如果你想让子类执行，必须覆写父类的方法。但若反过来，子类参数类型的范围小于父类，那么父类存在的地方，子类就未必可以存在。则子类就会被执行，这会影发业务逻辑混乱，因为在实际应用中父类一般是抽像类，子类是实现类，这样的一个子类会歪曲父类的意图。

4.覆盖或实现父类方法时输出结果的类型应小于等于父类的结果类

型

比如，父类的一个方法返回值是类型T，子类的相同方法(重载或覆盖)的返回值是S，那么里氏替换原则就要求S必须小于等于T，也就是说，要么S和T是同一个类型，要么S是T的子类。

输入参数：大于等于

输出参数：小于等于

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

采用本原则时，应该尽量避免子类有“个性”，一旦子类有了个性，与父类之间的关系就难以调和。把子类当做父类用，子类的个性被抹杀；把子类单独作为一个业务来使用，则代码间的耦合关系就过于复杂缺乏类替换的标准。