Question

一般来说，为什么每个界面要争取三到五个成员？

然后，这样的事情出了什么问题？

interface IRetrieveClient
{
    Client Execute(string clientId);
}

interface ISaveClient
{
    bool Execute(Client client);
}

interface IDeleteClient
{
    bool Execute(string clientId);
}

当我看到这个时，它尖叫着“反模式！”因为接口没有完成任何事情，特别是当应用程序的设计者希望每个接口与实现它的类具有一对一的关系时。

读取：实现接口后，永远不会再次重新实现。现在，我没有设计这个系统，在我看来他们想要做的就是实现命令模式的某个版本，但在与开发人员交谈时，他们似乎没有得到它。

Answer 1

我非常广泛地使用单接口方法模式的一个领域是泛型和一些通用的调度基础架构。

例如：

public interface IValidateEntities<T>
{
    bool Validate(T entity);
}

然后当需要对某种类型的实体做某事时，我们可以使用反射来找出要调用的实现（反射结果通常会提前缓存）。

我前段时间对这种模式进行了演示，可以在这里查看：

http://www.infoq.com/presentations/Making-Roles-Explicit-Udi-Dahan

Answer 2

这对我来说完全合情合理。我很高兴每个接口都有少量方法（或者实际上是一种方法）。

请注意，组合接口的好处是，您可以（比方说）通过适当的方式选择性地呈现类的不同视图。例如你可以构造/修改一个类，然后通过一个更受限制的接口（例如，有一个只读接口）来呈现它（缩小它）

e.g。

interface Readable {
   Entity get();
}

interface Writeable {
   void set(Entity e);
}

一个类可以实现这两个接口，以便你可以改变它，然后你可以简单地将它作为Readable对象呈现给客户端，这样它们就不会改变它。由于细分了接口，这是可能的。

Answer 3

您应该小心使用一般规则并严格应用它们。如果你需要的话，你的方法本身没有任何问题。

但您可能想要考虑以下替代方案：

interface IClient
{
     Client Retrieve(string clientId);
     bool Save(Client client);
     bool Delete(string clientId);
}

这种方法的优点是当你使用注入时，你只需要注册一个实例，而你的构造函数中只有一个接口。

因此，如果它在逻辑上属于一个，我会将它保留在一个界面中，因为它可以减少混乱并且不那么复杂。

Answer 4

设计中最重要的是要遵守Robert Martin所说的单一责任原则。在你的情况下，我认为L-Three提出的是非常合理的，因为客户将有一个责任 - 与数据库（或服务，e.t.c。）交谈。因此，如果您发现IClient中的方法由于某种原因将完全不同并且破坏了SRP，那么您可以将它拆分为多个接口，我不认为接口只有一个方法是一个问题。例如，一个很好的例子是名为IKeyGenerator的接口，它以线程安全的方式生成密钥。该界面只有GetNextKey()方法，这已经足够了。

为什么要尽可能争取多个接口成员？

4 个答案: