Polymorphism – Handling Unused Function Parameters

interfacesparameterspolymorphism

I had a discussion with a co-worker about interface members having parameters that some implementations don't use.

Say I have an interface

interface IDoctor
{
    string GetMedicalOpinion(Age age, Weight weight, SleepSchedule sleepSchedule, Symptom symptom)
}

Implementations of IDoctor won't necessarily use every method parameter:

class BadDoctor : IDoctor
{
    string GetMedicalOpinion(Age age, Weight weight, SleepSchedule sleepSchedule, Symptom symptom)
    {
        if (Symptom == Symptoms.Fatigue)
            return "You're sick!";
        return "You're okay."
    }
}

My co-worker thinks that the interface is poorly defined because there are implementations that don't use every method parameter.

I think this is fine. Having one method with all of the parameters gives us polymorphism — we can swap in IDoctors of varying competence without modifying the surrounding code. Also, the parameters are immutable data, so consumers shouldn't have any expectation that the function does anything other than return a string. Finally, the parameters are all things that consumers should have naturally, so providing the info isn't a burden on consumers.

Does this violate contemporary design principles? Is there really a problem with interface members having parameters that are used by some implementations, but ignored by others?

Best Answer

I think the main problem is actually caused due to a reason that has been widely discussed recently on this exact board, Should we avoid custom objects as parameters?

In order to call the method you defined, you inherently need to deconstruct the object the attributes belong to.

By changing the method signature to the one in the following example, you eliminate the need to pass unused parameters.

interface IDoctor
{
    string DetermineMedicalState(IPatient patient);
}

It really seems like all the properties you are passing belong to one patient anyway, so keep them together in an object. That's what objects are also used for, to reduce the number of parameters.

With this approach you know the method accepts an IPatient variable and couldn't care less which type of doctor extracts which information from it.

To answer the questions you asked, I don't really think the initial design violates any rules, as long as it respects the contract given by the interface. But it's not an elegant design either and perhaps not even the right one.

By passing an IPatient object you still have polymorphism at hand, thus haven't lost anything.

Related Solutions

F# Parameters – Why Not Annotate Function Parameters?

I don’t use F#, but in Haskell it is considered good form to annotate (at least) top-level definitions, and sometimes local definitions, even though the language has pervasive type inference. This is for a few reasons:

Reading
When you want to know how to use a function, it’s incredibly useful to have the type signature available. You can simply read it, rather than trying to infer it yourself or relying on tools to do it for you.
Refactoring
When you want to alter a function, having an explicit signature gives you some assurance that your transformations preserve the intent of the original code. In a type-inferred language, you may find that highly polymorphic code will typecheck but not do what you intended. The type signature is a “barrier” that concretises type information at an interface.
Performance
In Haskell, the inferred type of a function may be overloaded (by way of typeclasses), which may imply a runtime dispatch. For numeric types, the default type is an arbitrary-precision integer. If you don’t need the full generality of these features, then you can improve performance by specialising the function to the specific type you need.

For local definitions, let-bound variables, and formal parameters to lambdas, I find that type signatures usually cost more in code than the value they would add. So in code review, I would suggest you insist on signatures for top-level definitions and merely ask for judicious annotations elsewhere.

Java Polymorphism – Use Polymorphism or Bounded Type Parameters

These two examples are equivalent, and in fact will compile to the same bytecode.

There are two ways that adding a bounded generic type to a method as in your first example will do anything.

Passing the type parameter to another type

These two method signatures end up being the same in the byte code, but the compiler enforces type safety:

public static <T extends Animal> void addAnimals(Collection<T> animals)

public static void addAnimals(Collection<Animal> animals)

In the first case, only a Collection (or subtype) of Animal is allowed. In the second case, a Collection (or subtype) with a generic type of Animal or a subtype is allowed.

For example, the following is allowed in the first method but not the second:

List<Cat> cats = new ArrayList<Cat>();
cats.add(new Cat());
addAnimals(cats);

The reason is that the second one only allows collections of animals, while the first allows collections of any object that is assignable to animal (i.e. subtypes). Note that if this list were a list of animals that happened to contain a cat, either method would accept it: the issue is the collection's generic specification, not what it actually contains.

Returning objects

The other time it matters is with returning objects. Let us assume the following method existed:

public static <T extends Animal> T feed(T animal) {
  animal.eat();
  return animal;
}

You would be able to do the following with it:

Cat c1 = new Cat();
Cat c2 = feed(c1);

While this is a contrived example, there are cases where it makes sense. Without generics, the method would have to return Animal and you would need to add type casting to make it work (which is what the compiler adds to the byte code anyway behind the scenes).

Best Answer

Related Solutions

F# Parameters – Why Not Annotate Function Parameters?

Java Polymorphism – Use Polymorphism or Bounded Type Parameters

Related Topic