[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原则,我觉得只要在添加子类的时候很小心地看一下基类与基类使用者之间的契约,保证不会违反就可以了。
对这个原则,我的体会不深,主要是因为没有在实际项目中看到违背它的后果,不过作为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原则,我觉得只要在添加子类的时候很小心地看一下基类与基类使用者之间的契约,保证不会违反就可以了。