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

一般来说，你为什么要争取每个界面有三到五个成员？为什么要尽可能争取多个接口成员？

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

当我看到这个时，它尖叫着“Antipattern！”因为接口没有完成任何事情，尤其是当应用程序的设计者打算为每个接口与实现它的类建立一对一的关系时。

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

2013-06-20 user2505193

为什么你要努力一些数量接口的成员？ 'IDisposable'例如 –

我想说一个接口应该拥有尽可能多或者很少的成员，因为它对你的应用程序设计很有意义。在这种情况下，如果您的应用程序设计具有只能为第三方检索/读取的实现，或者只写，那么这是有意义的。还要注意，你也可以通过这种方式创建组合接口（例如'interface IChangeClient：ISaveClient，IDeleteClienet'）编辑：也就是说，如果你的应用程序设计不需要限制某些实现不能做某些事情，那么将其分成3个接口可能是不必要的复杂性。 –

IDisposable是完全有意义的，命令模式也是如此，但我不知道为什么不通过IClient使用get，save和delete成员来公开类似的内容。 – user2505193

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

请注意，组合接口的好处是，您可以（比如说）通过适当地施放选择性地呈现不同的类视图。例如您可以构建/修改课程，然后通过更受限制的界面（例如具有只读界面）呈现（缩小）

例如，

interface Readable { 
    Entity get(); 
} 

interface Writeable { 
    void set(Entity e); 
}

一个类可以实现这两个接口，这样你可以变异它，然后你可以把它展示给客户，仅仅作为一种Readable对象，使得它们可以发生变异它。由于细分接口，这是可能的。

来源

2013-06-20 13:06:04

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

但你可能要考虑以下替代：

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

这种方法的好处是，当你使用注射，你只需要注册一个实例，并且只在有一个接口的构造函数。

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

来源

2013-06-20 13:10:56

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

来源

2013-06-20 13:23:28

其中一个我非常广泛地使用单方法每界面模式的领域是泛型与一些通用调度基础结构。

例如：

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

然后，当有必要做一些与某些类型的实体，我们可以使用反射来找出实现调用（反射通常提前缓存的结果）。

我介绍了这种模式演示了一段时间回来了，它可用于观看在这里：

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

来源

2013-06-23 07:48:31

爱那个演示文稿。特别是有了反射，有时甚至可以有一个界面，甚至没有一个单一的方法，所以你有一些标记。你当然也可以就约定达成一致，以便命名提供相同类型的“标记”。就像NServiceBus以不显眼的模式处理消息一样。 –

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

回答

相关问题