c# - 接口(interface)继承——如何不破坏里氏代换原则和单一职责模式？

Question

我有一个通用存储库模式，现在我发现我需要一个自定义方法来实现此模式的一个特定实现，让我们调用实现 CustomerRepository 和方法 GetNextAvailableCustomerNumber。我有一些想法，但它们不符合面向对象设计的 SOLID 原则。

我首先考虑为该实现制作一个自定义存储库模式 (ICustomerRepository)，但这并不是很可行。经验告诉我，必须有一些我目前还没有考虑甚至不知道的其他方式。此外，我认为为路上的每一个颠簸发明一个新的存储库接口(interface)不应该那么轻易地完成。

然后我考虑让 ICustomerRepository 继承 IRepository 并只添加 GetNextAvailableCustomer 的方法签名，但这非常违背 Liskov 的替换原则，我相信它也稍微违背了单一职责模式。我仍然能够基于 IRepository 实现客户存储库，即使我只想使用 ICustomerRepository。我最终会得到两个备选方案，并且客户应该实现哪个接口(interface)将不再明显。在这种情况下，我希望它只能实现 ICustomerRepository，而不是 IRepository

解决这个问题的正确方法是什么？接口(interface)继承真的是可行的方法吗，或者是否有任何其他理想的符合 LSP 的首选方法？

这是我的通用存储库界面:

public interface IRepository<T>
    where T : IEntity
{
    T GetById(int id);

    IList<T> GetAll();

    IEnumerable<T> Query(Func<T, bool> filter);

    int Add(T entity);

    void Remove(T entity);

    void Update(T entity);
}

Answer 1

您实际上并没有违反里氏代换原则。利斯科夫说

objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program

在你的情况下你可以。根据您对 Liskov 的解释，几乎不允许类的继承和扩展。

我认为从 IRepository “继承”的 ICustomerRepository 就可以了。我仍然可以在任何使用 IRepostory 的地方替换 ICustomerRepository(给定 ICustomerRepository:IRepostory)

Liskov 防止子类的意外行为。最常用的(虽然不一定是最好的)示例似乎是正方形继承自矩形的示例。这里我们有一个被 Square 覆盖的 SetWidth 方法，但是 Square 也设置了高度，因为它是一个正方形。因此在子类中更改了原始方法定义，因此违反了原则。