你能用一个很好的 C# 例子来解释 Liskov 替换原则(SOLID 的“L”)吗?如果真的可以。
3 回答
(此答案已于 2013-05-13 重写,请阅读评论底部的讨论)
LSP 是关于遵循基类的契约。
例如,您可以不在子类中抛出新的异常,因为使用基类的异常不会这样。ArgumentNullException
如果缺少参数并且子类允许参数为空,则基类抛出相同的情况,这也是 LSP 违规。
下面是一个违反 LSP 的类结构示例:
public interface IDuck
{
void Swim();
// contract says that IsSwimming should be true if Swim has been called.
bool IsSwimming { get; }
}
public class OrganicDuck : IDuck
{
public void Swim()
{
//do something to swim
}
bool IsSwimming { get { /* return if the duck is swimming */ } }
}
public class ElectricDuck : IDuck
{
bool _isSwimming;
public void Swim()
{
if (!IsTurnedOn)
return;
_isSwimming = true;
//swim logic
}
bool IsSwimming { get { return _isSwimming; } }
}
和调用代码
void MakeDuckSwim(IDuck duck)
{
duck.Swim();
}
如您所见,有两个鸭子的例子。一只有机鸭和一只电鸭。电动鸭子只有在开机的情况下才能游泳。这违反了 LSP 原则,因为它必须打开才能游泳,因为IsSwimming
(这也是合同的一部分)不会像在基类中那样设置。
你当然可以通过做这样的事情来解决它
void MakeDuckSwim(IDuck duck)
{
if (duck is ElectricDuck)
((ElectricDuck)duck).TurnOn();
duck.Swim();
}
但这会破坏 Open/Closed 原则并且必须在任何地方实现(因此仍然会生成不稳定的代码)。
正确的解决方案是在方法中自动打开鸭子,并通过这样做使电动鸭子的行为与接口 Swim
定义的完全相同IDuck
更新
有人添加了评论并将其删除。它有一个我想解决的问题:
在使用实际实现( )时,在方法内部打开鸭子的解决方案Swim
可能会产生副作用。ElectricDuck
但这可以通过使用显式接口实现来解决。恕我直言,如果不打开它,您更有可能遇到问题,Swim
因为预计它会在使用IDuck
界面时游泳
更新 2
改写了一些部分以使其更清楚。
LSP 一种实用的方法
在我到处寻找 LSP 的 C# 示例的地方,人们都使用了虚构的类和接口。这是我在我们的一个系统中实现的 LSP 的实际实现。
场景:假设我们有 3 个数据库(抵押贷款客户、经常账户客户和储蓄账户客户)提供客户数据,并且我们需要给定客户姓氏的客户详细信息。现在,我们可能会根据给定的姓氏从这 3 个数据库中获得超过 1 个客户详细信息。
执行:
商业模式层:
public class Customer
{
// customer detail properties...
}
数据访问层:
public interface IDataAccess
{
Customer GetDetails(string lastName);
}
以上接口由抽象类实现
public abstract class BaseDataAccess : IDataAccess
{
/// <summary> Enterprise library data block Database object. </summary>
public Database Database;
public Customer GetDetails(string lastName)
{
// use the database object to call the stored procedure to retrieve the customer details
}
}
这个抽象类对所有 3 个数据库都有一个通用方法“GetDetails”,每个数据库类都扩展了该方法,如下所示
抵押客户数据访问:
public class MortgageCustomerDataAccess : BaseDataAccess
{
public MortgageCustomerDataAccess(IDatabaseFactory factory)
{
this.Database = factory.GetMortgageCustomerDatabase();
}
}
当前帐户客户数据访问:
public class CurrentAccountCustomerDataAccess : BaseDataAccess
{
public CurrentAccountCustomerDataAccess(IDatabaseFactory factory)
{
this.Database = factory.GetCurrentAccountCustomerDatabase();
}
}
储蓄账户客户数据访问:
public class SavingsAccountCustomerDataAccess : BaseDataAccess
{
public SavingsAccountCustomerDataAccess(IDatabaseFactory factory)
{
this.Database = factory.GetSavingsAccountCustomerDatabase();
}
}
一旦设置了这 3 个数据访问类,现在我们将注意力吸引到客户端。在业务层中,我们有 CustomerServiceManager 类,它将客户详细信息返回给其客户。
业务层:
public class CustomerServiceManager : ICustomerServiceManager, BaseServiceManager
{
public IEnumerable<Customer> GetCustomerDetails(string lastName)
{
IEnumerable<IDataAccess> dataAccess = new List<IDataAccess>()
{
new MortgageCustomerDataAccess(new DatabaseFactory()),
new CurrentAccountCustomerDataAccess(new DatabaseFactory()),
new SavingsAccountCustomerDataAccess(new DatabaseFactory())
};
IList<Customer> customers = new List<Customer>();
foreach (IDataAccess nextDataAccess in dataAccess)
{
Customer customerDetail = nextDataAccess.GetDetails(lastName);
customers.Add(customerDetail);
}
return customers;
}
}
我没有展示依赖注入来保持简单,因为它现在已经变得复杂了。
现在,如果我们有一个新的客户详细信息数据库,我们只需添加一个扩展 BaseDataAccess 并提供其数据库对象的新类。
当然,我们需要在所有参与的数据库中使用相同的存储过程。
最后,CustomerServiceManager
类的客户端只会调用 GetCustomerDetails 方法,传递 lastName 并且不应该关心数据的来源和方式。
希望这将为您提供了解 LSP 的实用方法。
这是应用里氏替换原则的代码。
public abstract class Fruit
{
public abstract string GetColor();
}
public class Orange : Fruit
{
public override string GetColor()
{
return "Orange Color";
}
}
public class Apple : Fruit
{
public override string GetColor()
{
return "Red color";
}
}
class Program
{
static void Main(string[] args)
{
Fruit fruit = new Orange();
Console.WriteLine(fruit.GetColor());
fruit = new Apple();
Console.WriteLine(fruit.GetColor());
}
}
LSV 声明:“派生类应该可以替代它们的基类(或接口)”和“使用对基类(或接口)的引用的方法必须能够在不知道或不知道细节的情况下使用派生类的方法。”