0

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

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

interface IRetrieveClient
{
    Client Execute(string clientId);
}

interface ISaveClient
{
    bool Execute(Client client);
}

interface IDeleteClient
{
    bool Execute(string clientId);
}

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

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

4

4 回答 4

1

我非常广泛地使用每个接口单一方法模式的一个领域是使用泛型以及一些通用调度基础设施。

例如：

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

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

不久前我就这种模式做了一个演示，可以在这里查看：

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

于 2013-06-23T07:48:31.910 回答
0

设计中重要的一点是要遵守 Robert Martin 所说的单一责任原则。在您的情况下，我认为 L-Three 提出的建议是非常合理的，因为客户将承担一项责任 - 与数据库（或服务等）交谈。因此，如果您看到 IClient 中的方法由于某种原因会变得完全不同并且破坏了 SRP，那么您可以将它拆分为多个接口，我认为如果一个接口只有一个方法，这不是问题。例如，一个很好的例子是一个调用接口IKeyGenerator，它以线程安全的方式生成密钥。该接口具有GetNextKey()足够完美的方法。

于 2013-06-20T13:23:28.103 回答
0

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

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

例如

interface Readable {
   Entity get();
}

interface Writeable {
   void set(Entity e);
}

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

于 2013-06-20T13:06:04.747 回答
0

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

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

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

这种方式的好处是，当你使用注入的时候，你只需要注册一个实例，你的构造函数中只有一个接口。

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

于 2013-06-20T13:10:56.350 回答