Getters and setters under should be used under ALL circumstances

Miscellaneous Topics
#21

If small methods do not get properly inlined, then they CAN make trouble. In the case of a fractal drawing program, I wrote a class for manipulating complex numbers with methods for basic algebraic operations. The simple complex operation “z^2 + c” would involve two method calls. After hundreds of iterations, this is quite a lot of method calls, and it turned out that manually inlining these bits increased efficiency several times. The method bodies themselves were just two or three lines with a couple of multiplications and assignments.

I can’t imagine the horrors of further using getters and setters in that situation (which was, by the way, completely unnecessary since it all went on inside the class itself).

#22

[quote] …it turned out that manually inlining these bits increased efficiency several times.
[/quote]
On the client VM I can imagine things to be not optimal, but was this also the case on the server VM?

#23

From an OO perspective you preferably shouldn’t expose the internal state of objects at all, neither in the form of naked variables nor variables wrapped in getters/setters, because it breaks encapsulation. You should ask the object to do stuff instead of shuffling data in and out of it. You should push information onto it rather than pulling it out.

Getters/setters have very little to do with OO. Sure, they offer a slight data abstraction but that’s seldom utilized anyway. How often do you really change the internal representation of a variable leaving the getter/setter methods intact? If a class have variables you really want to expose and you feel there’s a performance issue you can as well skip the getters/setters.

#24

Two Comments:

(1) Getters and Setters add NO overhead in a modern VM. They get inlined away.

(2) The reason to use them is for future proofing. In the future you might want to a sub-class that has the same access but does more invovled calculation for those values/.

Getters and Setters abstract the conceptual interface, the “contract” from the implementation and thus are always a good idea.

Having said that, Im lazy and dont create them many times where I am really sure I wont ever override. Soemtimes thats bitten me and Ive had to go back and fix the wrong assumption later, I’ve actually seen languages thjat create “implied setters and getters”, much like Java has an impleid default constructor. Thats probably the best of all worlds…

#25

There’s a problem with this statement. It says that data abstraction is good and getters/setters will give you data abstraction so therefore go ahead and make every variable publicly available. This is not a good idea. To mechanically promote variables to the “conceptual interface” is not data abstraction. It’s a flagrant break of the principle of encapsulation and bad.

This “getter/setter on every variable in sight” mentality is confused with good OO. Instead use as few getters/setters as possible, preferably none. If you really want to expose variables there’s little or no benefit in using getters/setters because then you most likely have what in C++ is called a concrete class. It’s a class you design to be used as a primitive.

#26

Uj speaks the truth.

Cas :slight_smile:

#27

No, I did NOT say that. Please do not mis-characterize my statements.

We were explicitly talking about values you wish to expose. In that context I said that setters and getters are always a good idea.

There are lots of things that shoudl be “private”, thats why its in the language.

Edit: Note that, udner certain very specific conditions, it MAY be also useful to use getters and setters that are not exposed beyond your own children.
This allows a child to modify the way the value is obtained for the entire class. Its certainyl nto worth always doing but under the right circumstances it can add flexabiltiy to your classes.

#28

As someone else has mentioned, properties in .NET get converted into standard get and set method calls by the compiler. Take the following C#:


public class Foo {
	private int a;
	
	public int A {
		get {
			return a;
		}
		set {
			a = value;
		}
	}
}

WHen you compile this class then look at the generated MSIL, you will find

int get_A()

and

void set_A(int value)

I dislike properties, because there is no way from the syntax to know if a property is read only or write only. With getters and setters it’s plainly obvious.