OOD之Liskov替换原则

本文介绍了Liskov替换原则(LSP),强调子类型须能在不破坏程序正确性的前提下替换其基类型。通过手机充值通知商户的例子,展示了如何在实践中遵循LSP原则。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

[u][i]这个系列是早前发布在部门wiki上的,引导组里的兄弟入门OOD,希望同样对刚刚走到OOD门前的同学有用。 [/i][/u]

对这个原则,我的体会不深,主要是因为没有在实际项目中看到违背它的后果,不过作为Bob叔叔OOD基础原则的最后一个,还是要在这里介绍一下。这个原则的说明如下:
[b]子类型必须能够替换掉他们的基类型。[/b]

听起来是一个很简单的描述,基于继承的设计中似乎子类型总是可以替换它的基类型。但要注意,基类是一个抽象,用子类对基类进行替换要保证使用这个抽象的类的行为不被破坏。还是用手机充值完成通知商户那个例子来说明:

[img]http://dl.iteye.com/upload/attachment/151256/e5233216-4f11-32f3-af44-7491575024a3.jpg[/img]

假设,在定义接口MerchantCallback的时候,notifyMerchant方法并没有声明抛出异常,因而使用这个抽象的MobileChargingServiceImpl类中没有做相应的异常处理。但是有一天,我们需要添加一个新的商户通知实现,这个商户的通知机制会抛出异常,那么这个子类的添加就会破坏LSP原则,因为它为MobileChargingServiceImpl带来了风险,它没有完全遵循MerchantCallback的接口契约,它不能完全替换它的基类。
实践中遵循LSP原则,我觉得只要在添加子类的时候很小心地看一下基类与基类使用者之间的契约,保证不会违反就可以了。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值