Question

我正在创建一个控制台应用程序，用于学习状态和观察者模式。该程序基于一个基本订单系统，其中每个订单可以具有状态（待定，就绪，提交，即状态模式），并且有兴趣在订单更新时接收订单通知的订户被通知（观察者模式）。

Order类正在实现三个接口; IOrder，IOrderState和IObservable但我意识到相反，我可以让接口继承。哪种方法会更好？你什么时候分别从每个接口实现类实现而不是说，IOrder继承其他两个接口？

例如：

public class Order : IOrder, IOrderState, IObservable

或

public interface IOrder : IOrderState, IObservable

修改我可能刚刚回答了我的问题 - 如果你确定实现它的对象（Order类）将始终需要使用这些方法，我是否认为你会使IOrder接口继承其他两个接口？如果您不确定是否需要接口方法，或者其他类可能是订阅者不需要观察的订单，那么您是否会在类级别单独包含接口？

Answer 1

根据ISP (Interface Segregation Principle)规则，IOrder接口应该实现IOrderState, IObservable接口。因此，无论哪个类实现IOrder，它都将实现其他2个接口。

所以第二种情况更合适。即

public interface IOrder : IOrderState, IObservable

Answer 2

我认为这实际上取决于Interfaces的含义。虽然在你的例子中，分离这些接口并没有多大意义，因为它们看起来太靠近了。

但是如果你能想到一个类只需要IOrder而不需要其他两个的情况，你可能想要拆分它们。

让我们来看看访问修饰符。如果继承接口，则所有接口都可能是公共可见的。如果您只想在内部使用Orderstate和Observation，则必须将它们分开。

E.g。使用你的库的人应该只知道IOrder而不是IOrderstate所暴露的内容。

Answer 3

在设计类型时，您必须了解用例，或者至少要考虑它们在创建界面时，您应该考虑其可能的实现。不是每个类都应该用接口补充。

当你的图书馆中的每个课程都是这样的时候：

interface IMyClass {}
class MyClass : IMyClass {}

然后这是再次看一下类型设计的原因。你的班级库很有可能下地狱。我现在必须支持一些遗留代码，几乎每个内部类都有一个耦合的内部接口，这个类是一个单独的实现。老实说，我想禁止我以前的同事再使用接口。

如果您可以想象任何其他IOrder的影响，那么请创建IOrder接口。否则，扔掉它（例如，我无法想象两个或更多不同的IOrderState实现）。

如果每个IOrder必须为IObservable，则从IOrder继承IObservable。这完全取决于你的用例。

Answer 4

关于您的具体用例的一些信息，答案将不会非常准确，但我会尝试给您一些指示/提示。

我会说你需要考虑你的具体情况，而不是一般的和共同的原则。

也许您可以问自己以下问题：

实际上，我会问这类问题，以确定该怎么做。

另一方面，您可以考虑一个更灵活的架构，其中 Order应该实现的可以通过通用约束来定义：

public void Add<TOrder>(TOrder order) where TOrder : IOrder
{
}

但是当你需要跟踪订单的状态时，你可以这样做：

public void SaveState<TOrder>(TOrder order) where TOrder : IOrder, IOrderState
{
}