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.
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.