Liskov替代原则也适用于实现接口的类吗? [英] Does Liskov Substitution Principle also apply to classes implementing interfaces?
问题描述
1)LSP是否也适用于接口，这意味着我们应该能够使用实现特定接口的类并仍然获得预期的行为?
1) Does LSP also apply to interfaces, meaning that we should be able to use a class implementing a specific interface and still get the expected behavior?
2)如果确实如此，那么为什么使用接口编程被认为是一件好事(顺便说一句，我知道对接口进行编程会增加松散耦合)，如果使用继承的主要原因之一是由于违反LSP的风险?也许是因为:
2) If that is indeed the case, then why is programming to an interface considered a good thing ( BTW- I know that programming to an interface increases loose coupling ), if one of the main reasons against using inheritance is due to risk of not complying to LSP? Perhaps because:
a)松耦合的好处超过了不遵守LSP的风险
a) benefits of loose coupling outweight the risks of not complying to LSP
b)与继承相比，类(实现接口)不遵守LSP的机会要小得多
b) compared to inheritance, chances that a class ( implementing an interface ) will not adher to LSP are much smaller
谢谢
推荐答案
LSP是否也适用于接口，这意味着我们应该能够使用实现特定接口的类并仍然获得预期的行为?
Does LSP also apply to interfaces, meaning that we should be able to use a class implementing a specific interface and still get the expected behavior?
LSP适用于合同.合同可以是类或接口.
LSP applies to the contract. The contract may be a class or an interface.
如果确实是这种情况，那么为什么对接口进行编程被认为是一件好事(顺便说一句，我知道对接口进行编程会增加松散耦合)，如果使用继承的主要原因之一是由于存在以下风险:不符合LSP?也许是因为:
If that is indeed the case, then why is programming to an interface considered a good thing ( BTW- I know that programming to an interface increases loose coupling ), if one of the main reasons against using inheritance is due to risk of not complying to LSP? Perhaps because:
这与接口或类无关.这是违反合同的事.假设您在 IVehicle (或 VehicleBase )中有一个 Break()方法.任何打电话给它的人都会期望车辆破损.想象一下，如果其中一种实现没有中断，就会感到惊讶.这就是LSP的全部意义.
It's not about an interface or a class. It's about a violation of the contract. Let's say that you have a Break() method in a IVehicle (or VehicleBase). Anyone calling it would expect the vehicle to break. Imagine the surprise if one of the implementations didn't break. That's what LSP is all about.
a)松耦合的好处超过了不遵守LSP的风险
a) benefits of loose coupling outweight the risks of not complying to LSP
嗯?
b)与继承相比，类(实现接口)不遵守LSP的机会要小得多
b) compared to inheritance, chances that a class ( implementing an interface ) will not adher to LSP are much smaller
嗯?
您可能想阅读我的SOLID文章，以更好地理解该原理: http://blog.gauffin.org/2012/05/solid-principles-with-real-world-examples/
You might want to read my SOLID article to understand the principle better: http://blog.gauffin.org/2012/05/solid-principles-with-real-world-examples/
更新
详细说明-通过继承，虚拟方法可能会占用私有成员，而覆盖这些虚拟方法的子类将无法访问这些私有成员.
To elaborate - with inheritance virtual methods may consume private members, to which subclasses overriding these virtual methods don't have access to.
是的.那挺好的.成员(字段)应始终受到保护(=声明为私有).只有定义它们的类才真正知道它们的值.
Yes. That's good. members (fields) should always be protected ( = declared as private). Only the class that defined them really know what their values should be.
此外，派生类从父类继承上下文，因此将来对父类等的更改可能会破坏它.
Also, derived class inherits the context from parent and as such can be broken by future changes to parent class etc.
这违反了开放/封闭原则.即，通过更改行为来更改集体合同.类应该扩展而不是修改.当然，不可能一直如此，但是更改不应使类的行为有所不同(错误修正除外).
That's a violation of Open/closed principle. i.e. the class contract is changed by changing the behavior. Classes should be extended and not modified. Sure, it's not possible all the time, but changes should not make the class behave differently (other than bugfixes).
因此，我认为让子类兑现合同比使类实现接口兑现合同更困难
Thus I feel it's more difficult to make subclass honour the contract than it is to make class implementing an interface honour it
有一个普遍的原因导致很难通过继承进行扩展.那是因为该关系不是真正的 is-a 关系，而是开发人员只想利用基类功能.
There is a common reason to why extension through inheritance is hard. And that's because the relationship isn't a true is-a relationship, but that the developer just want to take advantage of the base class functionality.
错了.那就更好地使用合成了.
That's wrong. Better to use composition then.
这篇关于Liskov替代原则也适用于实现接口的类吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
