未使用的接口参数
我有一个由三十个具体类实现的接口。具体实现者分为两组，每组都继承自一个公共抽象类。抽象类为具体实现者定义构造函数，包括为两侧的每个“侧”传入数据库连接对象（除了其他差异之外，它们具有不同的数据库）。
当前的所有接口方法均具有具体类“完成工作”所需的多个参数，但并非所有实现者都使用所有参数。
今天早上，当我向接口添加一个新方法时，我意识到只有一个具体实现者需要数据库连接，而其余的实现者则不需要它。所以，这让我想知道，我应该将它作为参数传递吗？需要“完成工作”，但仅针对其中一个具体类，并且该类已经具有数据库连接。如果我将数据库连接作为接口参数传入，那么其他 29 个类将不会使用它。
对于可接受的接口参数，应该画一条什么样的线？任何有关该主题的阅读/内容我也会感激不尽。
I have an interface that is implemented by thirty concrete classes. The concrete implementers are subdivided into two groups, with each group inheriting from a common abstract class. The abstract classes define the constructors for the concrete implementers, including passing in a database connection object for each "side" of the two sides (they have different databases, among other differences).
All the current interface methods each have several parameters needed for the concrete classes to "get the job done", but not all are used in every implementer.
When I went to add a new method to the interface this morning, I realized that the database connection is going to be needed for only one of the concrete implementers, but the rest will not need it. So, that gets me wondering, should I pass it in as a parameter? It is needed to "get the job done", but for only one of the concrete classes, and that class has the database connection already. If I passed the database connection in as an interface parameter, then the other 29 classes will not use it.
What is a good line to draw for what is an acceptable interface parameter? Any reading/content on the subject I will thankfully devour as well.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
在我看来，这个界面正在慢慢变成一个“上帝界面” 。通过问自己几个问题来检查情况是否如此：
Serialized之类的名称，或者更准确地称为SerializedAndSomethingElse。不。事实上，如果数据库连接仅由其中一个实现者需要，那么听起来它根本不属于接口。接口应该代表抽象 API，听起来好像数据库连接是该 API 实现的一部分。
That sounds to me a lot like the interface is slowly turning into a bit of a "god interface". Check whether this is the case by asking yourself a couple of questions:
Serializable, or would it more accurately be calledSerializableAndSomethingElse.No. In fact, if the database connection is only needed by one of the implementers then it doesn't sound like it belongs in the interface at all. The interface should represent the abstract API, where as it sounds as though the database connection is a part of the implementation of that API.
如果它不是抽象的一部分——那么它就不应该出现在接口中。如果它只被 30 个实现类中的 1 个使用，那么它绝对不是抽象的一部分。
我在谷歌上快速搜索了“api design”，第一个结果是：
演示文稿的幻灯片作者：约书亚·布洛赫。
他的观点与您的问题相关：
听起来您有一个棘手的问题需要解决 - 但祝您好运！
If it's not part of the abstraction -- then it shouldn't be in the interface. And if it's only used by 1 of 30 implementing classes, then it's definitely not part of the abstraction.
I did a quick google search for 'api design' and the first hit was:
slides of a presentation by Joshua Bloch.
His points that are relevant to your question:
It sounds like you have a tough problem to solve -- but good luck!
听起来您正在遵循实现驱动的设计，而不是用例驱动的设计。通过考虑来电者的观点，您将能够自己回答其中一些问题。我在这篇博客文章中获得了更多详细信息：
http ://theamiableapi.com/2011/08/29/considering-the-perspective-of-the-caller/
干杯，
费伦茨
It sounds like you are following implementation driven design as opposed to use case driven one. You'll be able to answer some of these questions yourself by considering the perspective of the caller. I've got more details in this blog post:
http://theamiableapi.com/2011/08/29/considering-the-perspective-of-the-caller/
Cheers,
Ferenc
各种类的构造函数参数应该是处理中使用的协作者（或配置值）。这就是如何。对于 30 种不同的实现，这些可能会有所不同。如果某些数据库连接需要而不是其他数据库连接，则仅将其作为构造函数参数提供给其中一个。
然后，该接口构成了应该完成的处理的基础。这就是什么。
您应该争取一个 API 名称、参数和方法处于同一概念级别的接口。构造函数参数可能处于较低的概念级别。
The constructor arguments to your various classes should be collaborators (or configuration values) used in processing. This is the how. These can vary for the 30 different implementations. If the database connection is required for some and not others, then only supply it as a constructor argument to one.
The interface then forms a basis for the processing should be done. This is the what.
You should strive for an interface where the API name, arguments and methods are at the same conceptual level. Constructor arguments are likely to be at a lower conceptual level.