3

I found some overrides methods that not use all the parameters that are in the signature of the method.

ex:

@Override
protected void setSomething(Object a, Object b, Object c) {
    this.a = a
    this.b = b;
    // the parameter c is not used (ignored)
}

Normally the parent class shouldn't be care about how the children will implements the abstract methods.

But in MHO, arguments of a method are to be use, it's very rare when a sub-class implementation doesn't need a parameter, when this happens then probably there's a problem with the design of the interface or with the abstract class.

The base of one function is: inputs -> process of inputs -> output.

Sometimes you need to calculate these inputs, but if you don't go to use some of these inputs in the process of your function, these inputs shouldn't be place as inputs of your function.

You could jump the calculation of these inputs calling an accurate function that use all the inputs, so the accurate function.

The only case where this situation could be acceptable, is when we don't want the behavior of the parent class, so we could write: 

@Override
protected void setSomething(Object a, Object b, Object c) {
      //Nothing to do
}

Or

@Override
 protected void setSomething(Object a, Object b, Object c) {
  throw new UnsupportedOperationException(...);
}

Sonar says :

Unused parameters are misleading. Whatever the value passed to such parameters is, the behavior will be the same.

My Question is: When we override a method we should use all the parameters that are in the method signature?

When I says 'use all the parameters', I try to say that all the parameters that are in the method signature, are really use in the body (implementation) of the method.

Jesus Zavarce
  • 1,729
  • 1
  • 17
  • 27
  • 1
    "I found some overrides methods that not use all the parameters that are in the signature of the method" where have you seen this? – Neilos Sep 30 '15 at 11:04
  • 1
    "When we override a method we should use all the parameters that are in the signature of the method?". Definitely not. Why should a subclass need all the parameters? – xehpuk Sep 30 '15 at 11:07
  • Forgive me I think I misunderstood you. I think that you mean that simply the args are passed in but ignored? If that is the case then that is fine, you do not have to do anything with the parameters. Initially I thought you meant that the superclass and subclass methods' signatures did not match, which is not possible. – Neilos Sep 30 '15 at 11:08
  • @Neilos i updated my question with an exemple, and yes is that the point, ignore the parameter in the body of the override method – Jesus Zavarce Sep 30 '15 at 11:11
  • @JesusZavarce yes you can ignore the paramaters in your implementation of the method; but the signature of an overridden method must match the signature of an ancestor. – Neilos Sep 30 '15 at 11:12
  • @Neilos yes i know that i can do that, but i don't think that is good, this could indicate a problem with the design of the interface. – Jesus Zavarce Sep 30 '15 at 11:23
  • possible duplicate of [Overloading and overriding](http://stackoverflow.com/questions/673721/overloading-and-overriding) – Raedwald Sep 30 '15 at 11:23
  • 1
    @JesusZavarce It could indicate a problem yes, but it may also not be a problem. Each case would have to be assessed on a case by case basis, however generally speaking there is not grand universal rule saying that it is bad, in fact I can think of times when you definitely would want to have an interface implement a specific signature but the concrete class would ignore the parameter, however other implementations would not ignore the parameter. – Neilos Sep 30 '15 at 11:26

4 Answers4

6

When we override a method we should use all the parameters that are in the signature of the method?

When you override a method, the overriden method must define the same parameters as the super-method.

You're not obligated to use all the parameters in the implementation - this depends on what you want to achieve with this implementation and sometimes not all parameters may be needed.

However, having unused method parameters within the method implementation is a sign of a poor design. When defining a method (being abstract or implemented), you should try answer the questions of "Why would I need this parameter?" and "Will this parameter be always used?". If it's possible to have cases where some parameters will not be used in the implementation, then you could define a few overloaded methods.

Take this example, for instance. Let's have this method

void someMethod(String first, String optionalParameter) { ... }

The second parameter is optional (i.e. may be needed or may not be) - you could pass null or anything when the parameter is not needed. In this case, I would overload two methods

void someMethod(String first) { ... }

void someMethod(String first, String second) { ... }

and I will also make sure that all the parameters are used in the corresponding implementation.

Konstantin Yovkov
  • 62,134
  • 8
  • 100
  • 147
  • So do you think e.g. [`DocumentFilter`](https://docs.oracle.com/javase/8/docs/api/javax/swing/text/DocumentFilter.html) is poor design? How to do it better? Having an overloaded method for every possibly unneeded parameter? It's hard to predict which parameters will _always_ be needed. – xehpuk Sep 30 '15 at 11:26
  • @xehpuk, I believe the implementation of `DocumentFilter` that comes within Swing uses all the parameters. It's not designers fault that you can implement their method without caring about some parameter value. They should not care about that - they should just provide explanation what are all parameters about. However, when you design an interface that you will actually implement across your system, you can do a pretty decent prediction about whether a parameter may be needed or not. – Konstantin Yovkov Sep 30 '15 at 11:35
  • Well, there's the design of an application, and there's the design of a framework or a library. Another example is `Observer`, where the second parameter to the `update` method is often not needed. There's even a parameterless method `notifyObservers` in `Observable`, which yields `null` for the second parameter. – xehpuk Sep 30 '15 at 12:07
1

Do you need to use all the parameters? No. You will often see examples like:

@Override
public void doFoo(String thingy) {
  // no-op
}

Or

@Override
public void doFoo(String thingy) {
  throw new UnsupportedOperationException(...);
}

But both are a sign of questionable design, somewhere. java.util.List or even java.util.Iterable, for example, both preclude the possibility of an immutable collection, by providing mutation methods. Immutable implementations have to throw UnsupportedOperationException.

Graham
  • 169
  • 6
  • Yes i agree with you, when yo don't want the behavior of one method of the parent class you could use @Override public void doFoo(String thingy) { // nothing to do } but my question is about the case when you put code inside your override method, and you ignored some inputs parameters. – Jesus Zavarce Sep 30 '15 at 11:27
  • It's a different case, but the same applies really. If you have an interface `Dog` with a method `void barkAt(Creature)`, and you have an implementation called `CrazyDog` which implements this method using something like `barkAtInternal(this);`, (i.e. bark at self, completely ignoring the `Creature` it's supposed to bark at) that's perfectly valid. It just starts raising some questions about the API itself, not your implementation. – Graham Sep 30 '15 at 13:00
0

If you override a method, than yes, you must use all the parameters.

But you can also overload a method - write a method with same name but different parameters. So if you dont use all of the parameters, you are overloading, not overriding.

class Accessor {

    public void doSomething(String attr) {}

}

class Child extends Accessor {

    // This is overriding
    @Override
    public void doSomething(String attr) {
       // ...
    }

    // This is overloading
    public void doSomething() {
       // ...
    }
}
Erveron
  • 1,908
  • 2
  • 25
  • 48
0

As you said: "we should" - but we don't have to. Sometimes an implemnting method even throws a RuntimeException, e.g. UnsupportedOperationException of the Java Collections Framework.

Würgspaß
  • 4,660
  • 2
  • 25
  • 41