将'final'修饰符与getter和setter一起使用是一个好主意吗？

Question

I was wondering why the final modifier is not used with getters and setters?

Why do this:

private int x;

public void setX(int x) 
{ 
  if(x >= 1) throw new IllegalArgumentException("X must be lower than 1");
  this.x = x; 
}

Instead of this:

private int x;

public final void setX(int x) 
{ 
  if(x >= 1) throw new IllegalArgumentException("X must be lower than 1");
  this.x = x; 
}

It does not improve the encapsulation? I have been trying to clarify it with google but I had not luck.

Thanks by advance.

Answer 1

One reason that you may want to leave a setter non-final is to let subclasses make their own, stricter, argument checks:

public class Subclass extends Superclass {
    public void setX(int x) { 
        if(x >= 0) throw new IllegalArgumentException("X must be negative");
        super.setX(x); 
    }
}

Of course this breaks Liskov Substitution Principle , because a subclass strengthens a precondition in a subtype.

Answer 2

The purpose of a final method in Java, is that it cannot be overridden or hidden by subclasses. Hence if you need that functionality for your getters / setters, it's perfectly fine to make them final, else there is no purpose for doing so.

Answer 3

I would strictly avoid setters when there may be another more robust possibility:

You may want to provide a setter in case you want to mutate a field.

Issue you mentioned:

What if a developer breaks the validation rules I provided, by overriding the setter...Should we go with final keyword?

I would say: "Dissuade him to do so" .

Indeed, declaring a setter is like saying to the world:
"You can provide me some field value and then you can do your own thing with me !" => procedural code

"Tell! Don't ask" philosophy would say:
"Client, tell me what to do, I will do."
And in general, your main "complex" logic would be in the main public api of the POJO.

I doubt that a developer would be tempted to override the full logic of a POJO without risking complete bad behaviors..

So, for instance, instead of declaring an opened setter to any value, force the value to be passed on the main method, so that you can control the flow:

public void computeWith(int x) {
  if(x <= 0) throw new IllegalArgumentException("X must be superior to 0");
  //code computing here.
}

You will notice that some fields might even not be needed any more in the POJO with this way of doing.

To sum up: It's easy to override a poor validation rule...but risky for a behaviour.

Just my 2 cents.

Answer 4

There are arguments both ways but if you make methods final (of any sort, not just getters or setters), somewhere down the line another developer will cursing you. It's very hard to predict how your class will be used in the future and restricting it by making it final usually makes like more difficult for a future developer.

eg some poor soul has got to integrate your code with a new application the company has just bought. It's 3pm on Friday afternoon and the demo is due on Monday morning. If only they could override a getter, they could force it to return a wrapped object from the new application and things would work. If that getter is final, they have to start changing, testing may be releasing your code so they end up working over the weekend.

So have some sympathy with future developers and don't make methods final unless you are really really sure. Even then I wouldn't bother.

Another use specifically for non-final getters is testing. It can be very convenient, particularly during integration tests with less than perfect code, to override a getter to inject a test instance of a class.