我有一个乘三十具体类实现的接口。具体实施者分为两组，每组从一个共同的抽象类继承。抽象类定义了具体实现者的构造函数，包括为双方的每个“边”传递数据库连接对象（它们具有不同的数据库以及其他差异）。未使用的接口参数
目前所有的接口方法各有到“完成工作”所需的具体类的几个参数，但不是所有的都在每一个执行者使用。
当我去到一个新的方法今早添加到界面，我意识到，数据库连接将被需要的只是具体的执行者之一，但其余部分将不再需要它。所以，这让我想知道，我应该把它作为参数传入吗？需要“完成工作”，但只有一个具体类，并且该类已经有数据库连接。如果我通过数据库连接作为接口参数，那么其他29个类将不会使用它。
什么是一个很好的线画，什么是可以接受的接口参数？任何关于这个问题的阅读/内容我都会感激地吞噬。
目前所有的接口方法各有所需 的具体类为“完成任务”的几个参数，但不是所有的都在每一个实施者使用 。
这对我来说听起来很像接口慢慢变成了一个"god interface"位。检查是否是这种情况下，先问自己几个问题：
Serializable，还是更准确地称为SerializableAndSomethingElse。当我去到一个新的方法今早添加到界面，我 意识到，数据库连接将被需要的只是 具体实施者之一，但其余部分将不再需要它。所以， 让我想知道，我应该通过它作为参数？
不。实际上，如果数据库连接只是其中一个实施者需要的，那么听起来不像它属于接口。该接口应该代表抽象API，就像数据库连接是该API实现的一部分一样。
如果它不是抽象的一部分 - 那么它不应该在接口。如果它只被30个实现类中的1个使用，那么它绝对不是抽象的一部分。
我做了快速谷歌搜索“API设计”和第一击是：
slides of a presentation by Joshua Bloch。
他的得分是有关你的问题：
这听起来像你有一个棘手的问题要解决 - 但祝你好运！
这听起来像你是跟随实施驱动的设计，而不是使用大小写驱动的设计。考虑到调用者的角度，您可以自己回答其中的一些问题。我已经在这个博客中得到了更多的细节：
http://theamiableapi.com/2011/08/29/considering-the-perspective-of-the-caller/
干杯，
费伦茨
我喜欢你的帖子，其实也相当多。好东西。 – Steve
构造函数的参数，以各个类应该是在加工中使用的合作者（或配置值）。这是如何。这些可以根据30个不同的实现而变化。如果数据库连接对于某些而不是其他数据库连接是必需的，那么仅将它作为构造函数参数提供给它。
接口然后形成应该完成处理的基础。这是什么。
你应该争取一个API名称，参数和方法处于相同概念级别的接口。构造函数的参数可能处于较低的概念级别。
听起来像数据库参数的接口应该从基本接口继承。 – Jodrell