Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Unused Interface Parameters

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.

like image 236
Steve Avatar asked Oct 05 '11 16:10

Steve


2 Answers

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.

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:

  • Does the interface represent a single behavioural concept in your model, or has it become a bit of a convenient dumping ground for method signatures from several concepts? Could it be called something like e.g. Serializable, or would it more accurately be called SerializableAndSomethingElse.
  • Could you carve the interface up into several more cohesive interfaces, and have the 30 different objects implement just the ones they need?

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?

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.

like image 92
razlebe Avatar answered Sep 23 '22 13:09

razlebe


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:

  • "When in doubt leave it out"
  • 'Don't let implementation details “leak” into API'
  • "API design is tough", but also, "API design is a noble and rewarding craft"
  • "Expect to make mistakes"

It sounds like you have a tough problem to solve -- but good luck!

like image 33
Matt Fenwick Avatar answered Sep 20 '22 13:09

Matt Fenwick