Is it bad practice to ignore some parameters while implementing a method of a interface?

Question

Should an interface method implemented by a class always use all parameters? By interface I do not necessarily mean actual interfaces, these could be other (abstract) classes which are extended, too.

I sometimes find it hard to use all parameters in all implementations. However, that seems to me as bad design. It makes me think of the mantra perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.

This especially applies in situations where (partially) optional behavior - such as flags that were previously set on the object instance - is refactored into an approach that makes use of polymorphism.

In pseudo code:

interface ValueProcesser {

    public Value doSomethingWithValue(value, parameter1, parameter2);
}

class Implementation1 implements ValueProcesser {

    // Does nothing - no optional behavior applies in here.
    public Value doSomethingWithValue(Value value, parameter1, parameter2) {
        return value;
    }
}

class Implementation2 implements ValueProcesser {

    // Behavior that only uses the first parameter
    public Value doSomethingWithValue(Value value, parameter1, parameter2) {
        doSomethingWithValueUsingParameter1(value, parameter1);

        return value;
    }
}

class Implementation3 implements ValueProcesser {

    public Value doSomethingWithValue(Value value, parameter1, parameter2) {
        doSomethingWithValueUsingParameter1AndParameter2(value, parameter1, parameter2);

        return value;
    }
}

Now for client code with a ValueProcesser instance, it is really easy to simply call:

    public void main() {
        ValueProcesser.doSomethingWithValue(value, parameter1, parameter2);
    }

and everything will work. The question is, should the unused parameters be refactored away somehow and how can I refactor to get rid of their redundancy?

For the record, it does not make sense to set those parameters as members of the Implementation classes.

Answer 1

In layman's terms:

As an implementor you are even allowed to write dummy implementations. You can just do nothing or return null (in the case of a function), or you can do something that is not what the method signature implies. But, will that achieve what you want?

It's perfectly valid for certain methods to accept null values in some parameters.

It's impossible to tell if you are incurring in a bad practice with examples like the ones you show. But chances are the interface violates the interface segregation principle and it's forcing you to implement methods that you don't need.

In the other hand, if parameter1 and parameter2 are just flags (you don't specify their type, so they could be booleans), then the design is flawed, because it implies that the method does more than one thing (Martin's Clean Code).

Bottom line:

You are being forced to implement a flawed design.

Answer 2

Since many languages allow for optional parameters in a function signature, clearly this is not an "always bad" practice. As for guidelines for whether it is a good practice I'd suggest the following (Java based examples but should apply to other languages)

1. Consistency: If there is a pattern of usage, such as a consistent optional "locale" argument for time and number formatting, that is good. If there are multiple options at the same place, like java.util.String having possible args for Charset and a String with the name of the Charset, that is suspect.

2. Documentation: Where possible, use the language's builtin varargs syntax for clarity. In your example, the method should be public Value doSomethingWithValue(Value value, Value...options).

3. Naturalness and Expressiveness: If all your coworkers "get it" quickly, you are on the right path. If everybody says "WTF why would I ever want an optional value fo PI?" you are likely going astray.

Answer 3

Your question is purely technical and has no practical examples. It is like asking "can I implement an interface method called Add to subtract the input values rather than add them up?"

Yes, you can, but the code will be useless. As will any interface implementation that does not implement the expected vehavior.

Take Substring. It takes a start and a length. Can you as an implementor ignore length? Yes, but any user will expect length to be effective when passed in. If you ignore any parameter your implementation will not be complete, each parameter on any interface method has a purpose.