设计模式原则之里氏替换原则

定义

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

所有引用基类的地方必须透明的使用其子类的对象。

定义明确的说，只要父类能出现的地方子类也可以出现，而且替换为子类不会产生任何错误或异常，但是反过来就不行，有子类出现的地方，父类未必就能适应。

---

继承

优点

代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性

提高代码的重用性

子类可以形似父类，但是又异于父类。

提高代码的可扩展性，实现父类的方法就可以了。许多开源框架的扩展接口都是通过继承父类来完成。

提高产品或项目的开放性

缺点

继承是侵入性的，只要继承，就必须拥有父类的所有方法和属性

降低了代码的灵活性，子类必须拥有父类的属性和方法，让子类有了一些约束

增加了耦合性，当父类的常量，变量和方法被修改了，需要考虑子类的修改，这种修改可能带来非常糟糕的结果，要重构大量的代码。

从整体来看，利大于弊。怎么才能让利的因素发挥最大的作用，同时减少弊的影响？解决方案是引入里氏替换原则。

---

里氏替换原则的规范

1.子类必须完全实现父类的方法

我们在做系统设计时，经常会定义一个接口或抽象类，然后编码实现，调用类则直接传入接口或抽象类，其实这已经使用了里氏替换原则。

注意： 

如果子类不能完整地实现父类的方法，或者父类的一些方法在子类中已经发生畸变，则建议断开继承关系，采用依赖，聚集，组合等关系代替继承。

2.子类可以有自己的个性

子类当然可以有自己的行为和外观，也就是方法和属性。但是里氏替换原则可以正着用，但是不能反着用。在子类出现的地方，父类未必就可以胜任。

下面的两条不适合ios，ios 没办法区分参数类型是放大还是缩小，不检测参数类型。

3.覆盖或实现父类的方法时输入参数可以被放大

4.覆盖或实现父类的方法时输出结果可以被缩小

---

场景模拟

我们以士兵射击为例。士兵设计可以使用很多枪步枪，手枪等等

---

士兵射击UML图

士兵设计UML图

---

简单代码

@protocol Gun

-(void)shoot;

@end

#import "Gun.h"

@interface Solider :

 NSObject-(void)setGun:(id) gun;

-(void)killEnemy;

@end

#import "Solider.h"

@interface Solider()

@property (nonatomic,strong) idsoliderGun;

@end

@implementation Solider

-(void)setGun:(id)gun{

    self.soliderGun = gun;

}

-(void)killEnemy{

    [self.soliderGun shoot];

}

@end

#import "Gun.h"

@interface HandGun : NSObject

@end

#import "HandGun.h"

@implementation HandGun

-(void)shoot{

    NSLog(@"手枪射击");

}

@end

#import "Gun.h"

@interface Rifle : NSObject

@end

#import "Rifle.h"

@implementation Rifle

-(void)shoot{

    NSLog(@"步枪射击");

}

@end

#import "Gun.h"

@interface MachineGun : NSObject

@end

#import "MachineGun.h"

@implementation MachineGun

-(void)shoot{

    NSLog(@"机关枪射击");

}

@end

测试代码

Solider * solider=[[Solider alloc]init];

id gun=[HandGun new];

  [solider setGun:gun];

[solider killEnemy];

gun=[Rifle new];

[solider setGun:gun];

[solider killEnemy];

gun=[MachineGun new];

[solider setGun:gun];

[solider killEnemy];

结果

2018-04-03 15:50:37.308121+0800 设计模式原则[54809:5684654] 手枪射击

2018-04-03 15:50:37.308331+0800 设计模式原则[54809:5684654] 步枪射击

2018-04-03 15:50:37.308615+0800 设计模式原则[54809:5684654] 机关枪射击

上面这个实现就是也就是开闭原则。

---

场景模拟变更

我们用步枪射击的时候，其实步枪有很多种，有AK,AUG狙击枪。但是当我们用狙击步枪的时候我们需要打开瞄准镜才能射击。

---

场景变更UML 图

士兵设计场景扩展UML图

---

场景变更代码

#import "Rifle.h"

@interface AUG : Rifle

-(void)zoomOut;

@end

#import "AUG.h"

@implementation AUG

-(void)zoomOut{

    NSLog(@"打开放大镜");

}

-(void)shoot{

    NSLog(@"使用狙击枪射击");

}

@end

solider 增加

-(void)killEnemy:(AUG*)aug;

-(void)killEnemy:(AUG*)aug{

    [aug zoomOut];

    [aug shoot];

}

测试代码

AUG * aug = [AUG new];

    [solider killEnemy:aug];

结果

2018-04-03 16:13:57.310796+0800 设计模式原则[60744:5711673] 打开放大镜

2018-04-03 16:13:57.311321+0800 设计模式原则[60744:5711673] 使用狙击枪射击

当我们给-(void)killEnemy:(AUG*)aug函数传入一个 MachineGun 对象的时候回发生崩溃

Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[MachineGun zoomOut]: unrecognized selector sent to instance 0x60000000a6a0'

从这里可以看出里氏替换原则的缺点了。不可以向下兼容

这证明了里氏替换原则可以正着用，但是不能反着用。在子类出现的地方，父类未必就可以胜任。

---

里氏替换原则经验

在项目中，采用里氏替换原则时，尽量避免子类的“个性”，一旦子类有了“个性”，这个子类和父类之间的关系就难调和，把子类当做父类使用，子类的“个性”被抺杀了，把子类单独作为一个业务来使用，则会让代码间的耦合关系变得扑朔迷离–缺乏类替换的标准。（别人的经验）

参考博客

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

源代码地址

下一篇博客

设计模式原则之依赖倒转原则