未使用的接口参数

Question

我有一个由30个具体类实现的接口。具体实现者细分为两组，每组继承自一个公共抽象类。抽象类定义具体实现者的构造函数，包括为双方的每个“侧”传递数据库连接对象（它们具有不同的数据库，以及其他差异）。

所有当前的接口方法都有几个参数，具体类需要“完成工作”，但并非所有参数都在每个实现者中使用。

当我今天早上去接口添加一个新方法时，我意识到只有一个具体的实现者需要数据库连接，但其余的不需要它。所以，这让我感到疑惑，我应该作为参数传递吗？需要“完成工作”，但仅针对其中一个具体类，并且该类已具有数据库连接。如果我作为接口参数传递数据库连接，那么其他29个类将不会使用它。

为什么是可接受的接口参数绘制什么是好的线？关于这个主题的任何阅读/内容我都会感激地吞噬。

Answer 1

  

所有当前的接口方法都需要几个参数   对于“完成工作”的具体课程，但并非所有人都使用   在每个实施者中。

这听起来很像我的界面慢慢变成"god interface"。通过问自己几个问题来检查是否是这种情况：

• 界面是否代表模型中的单个行为概念，或者它是否成为几个概念的方法签名的一个方便的倾销场？可以称之为例如Serializable，或者更准确地称为SerializableAndSomethingElse。
• 您是否可以将界面划分为几个更具凝聚力的界面，让30个不同的对象实现他们需要的界面？

  

当我今天早上去界面添加新方法时，我   意识到只需要数据库连接   其中一个具体的实施者，但其余的不需要它。所以，   这让我感到疑惑，我应该把它作为参数传递吗？

没有。实际上，如果只有其中一个实现者需要数据库连接，那么它听起来根本不属于接口。接口应该代表抽象API，听起来好像数据库连接是该API实现的一部分。

Answer 2

如果它不是抽象的一部分 - 那么它不应该在界面中。如果它只被30个实现类中的1个使用，那么它绝对不是抽象的一部分。

我快速谷歌搜索'api design'，第一次点击是：

slides of a presentation by Joshua Bloch

他的观点与您的问题相关：

• “如有疑问，请将其删除”
• '不要让实施细节“泄露”到API'
• “API设计很难”，而且“API设计是一种高贵而有益的工艺”
• “期待犯错”

听起来你有一个难以解决的问题 - 但祝你好运！

Answer 3

听起来你正在遵循实现驱动的设计而不是用例驱动的设计。通过考虑来电者的观点，您将能够自己回答其中的一些问题。我在这篇博文中有更多细节：

http://theamiableapi.com/2011/08/29/considering-the-perspective-of-the-caller/

干杯，

Ferenc

Answer 4

各种类的构造函数参数应该是处理中使用的协作者（或配置值）。这是如何。这些可能因30种不同的实现而有所不同。如果某些人而不是其他人需要数据库连接，则只将其作为构造函数参数提供给其中一个。

接口然后形成应该进行处理的基础。这是什么。

您应该努力寻找API名称，参数和方法处于相同概念级别的接口。构造函数参数可能处于较低的概念级别。