Performance vs. Laziness: Why use setters from within a class?

Question

I notice that web related code uses setter methods to set class fields instead of setting them directly since they are in scope. I find this to be a bit odd. Using setters is certainly safer, but if unit tests are implemented then bugs will be found. And it's not worth the extra stack call, imo.

Does any production code do this or is this just what you see in sample code online?

Edit: I have to make clear that I'm only talking about the case whereby the setter consists solely of a single assignment expression and nothing more.

Answer 1

You should follow the open/closed principle. Not using the setter means your class is not open to extension, because subclasses overriding the setter to maintain internal consistency by adding some according logic within the call will not have that logic executed and thus wind up with an inconsistent state.

As opposed to that, the argument with the extra call is virtually void.
Either the setter is overriden in a subclass, which means not using it is strictly not an option. Or the setter is not overriden, in which case any decent (JIT) optimizer will be able to inline it and thus achieve the same performance.

Answer 2

Never, ever, depend on unit tests when you can not depend on them. Safety 101: Guarantee it at compile-time instead of hoping, testing, or checking for it at run-time. If you have a setter for a variable, it's for a good reason, and you should not circumvent it without an even better reason.

Answer 3

To the performance aspect, a modern Just In Time compiler will In-Line the setter call if it is truly just a trivial set. There's no allocation of a new method stack or any of that cost to consider. Avoiding using getters/setters isn't really a performance concern even as a micro-optimization. (yes there is a cost to perform the inline, but the question refers to webapps, where ostensibly that happens once and the server remains up indefinitely.)

So some things in favor of using the setters

1) The setter may not be just a simple set for all time. I guess this is some personal opinion, but hoping automated tests will catch any and all bugs possibly introduced by skipping a setter that later gains side effects seems naive.

2) Set methods may be instrumented at run time by other frameworks. Persistence systems and aspect oriented programming frameworks can both add additional functionality to set methods that isn't seen in the source of the class. And again, just because one isn't in use now, doesn't mean it never will be.

3) A field that is accessed via a set method is clearly externally visible and changable state, as opposed to a truly private field with no accessors that is clearly internal state. It can improve understanding if the fields that represent only internally managed state "stand out" in code for lacking set calls.

4) Fewer worries about bugs where people leave off the 'this.' and set a method scope variable instead of the instance scope variable that they hid sloppily. (It's amazing how many people have conditioned themselves to completely ignore compiler warnings, even in IDEs that highlight them.)

In favor of not using the setter

1) All I can come up with is some people may find it easier to read.

Answer 4

A lot of it goes back to Bertrand Meyer's book and his Uniform Access Principle, or else with the Bean standard.

If we aren't filtering or massaging the data in our getter/setters I don't see a lot of point in writing getter/setter methods. If you have 'int getX()' and you change the implementation to double, you still will lean on the compiler to find the places to change. Likewise if you want to add an edit to an old public member.

Most people follow the rule slavishly. Why don't you try breaking it sometimes and seeing what it teaches you? Think about what situations would warrant additional wrapping, and when it is wasted effort. Keep notes.

Answer 5

In object oriented code, where the setters/getters of child classes can be different, you should always use them.

Answer 6

what constitutes a valid value and the accessor's implementation changes more often than you should care to manage manually.

it's highly tedious and error prone to verify all direct accesses follow the requirements set by the setter when implementations change. at that point, you realize you are validating and copying code all over that place (well, there are a lot of programmers that just trust they will not introduce a bug), which only makes the problem worse by giving you more implementations to validate manually and more chances for error. as the program evolves, it's easier and simpler to always use the setter and just move on with life.

in some cases, you will need direct access. this varies by language, but is common during initialization and destruction.

regarding performance: if the cost of function calls is a valid performance problem, you may be using the wrong tools, language, or approach. i do a lot of work in c++ -- the cost is trivial to nothing in optimized builds if well written. other languages are not as good in that regard.