CODEWITHSUNDEEP
ooplanguage-agnosticinterface
Steve
Steve

Reputation: 1636

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.

Upvotes: 7

Views: 2160

Answers (4)

WW.
WW.

Reputation: 24311

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.

Upvotes: 0

Ferenc Mihaly
Ferenc Mihaly

Reputation: 1155

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

Upvotes: 1

Matt Fenwick
Matt Fenwick

Reputation: 49105

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!

Upvotes: 2

razlebe
razlebe

Reputation: 7144

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.

Upvotes: 2

Related Questions