[ShaneK]

Greetings!

Today I was actually informed by my Computer Science II teacher that I use mutator methods too much, and I probably do, but I wanna know what y'all think. I use mutators even from within the class, and in the example he actually pointed out it was necessary because the mutator moderated the variable being set to make sure it was greater than 0 (for a basic dice rolling program).

Sometimes, however, I have mutators that do nothing other than set the variable and I even use them within the class. I know the purpose of encapsulation is closing the class off from the outside world, but is it okay that I even close the class off to everything but the getters and setters?

His idea is that calling the function takes up more resources than just setting it...which I could see, but is it really going to take up that many more resources?

Yours,
Shane~

[macosxnerd101]

If the setter method doesn't something beyond setting the variable, no need to use it within the class, in my opinion. If you delve into source code of various classes that come with the language SDK, you will find that many of them invoke their own setter methods if they do additional tasks, like the List classes in Java. I tend to agree with your professor here. Also note that if you have private members in a class, and it accepts an Object of itself as a param in a method, the class can access that Object's private members as well, so no need for getters here always, but I tend to use the setter methods in these cases.

[ShaneK]

Well, the reason I use it on variables that I don't moderate is because in the future I may want to moderate them and I wouldn't have to go back and change all of the source in the class just to do so effectively...

Yours,
Shane~

[Tom9729]

Using public variables is a bad idea for anything besides constants. You lose the ability to do any kind of validation or sanity checking, you lose the ability to drop in a quick print statement to see when a value is changed, you lose abstraction. Calling a method does not generate enough overhead that you need to worry about doing it.

It would be nice if Java implicitly generated getters/setters for all fields and enforced their use (eg. no public variables), but sadly that is not the case.

[cfoley]

Quote

His idea is that calling the function takes up more resources than just setting it...which I could see, but is it really going to take up that many more resources?

A good compiler should optimise that away to nothing. Java's JIT compiler certainly does... eventually.

Quote

Sometimes, however, I have mutators that do nothing other than set the variable and I even use them within the class. I know the purpose of encapsulation is closing the class off from the outside world, but is it okay that I even close the class off to everything but the getters and setters?

Part of the reason for setters is allowing you to change the class's implementation details without having to change the interface. Say you have a coordinate class with two setters. One to set the coordinates with cartesian x and y inputs and the other to set it with polar length and angle inputs. If you wanted to switch the internal storage from one to the other, you'll be thanking your lucky stars if you've been using setters internally!

More realistically, say you modify your class to cache the results of expensive calculations as and when they are made... but upon updating a certain field those results become invalid and need to b cleared. If you have been using setters throughout, all you need to do is add a clearCache() call to the setter. If you have been modifying it internally, you have to sprinkle them all over the place.

Don't get me wrong. I usually just modify the variable internally but that's mainly due to laziness. I guess a good reason to not use the setter is if it does a lot of expensive validation (null and bounds checking usually doesn't count) and you can prove that the internal value isn't going to be illegal. However, there is no reason you can't have a private setFieldUnchecked() method.