I just want someone to offer a simple explanation to the difference between using a GET/SET or copying a variable and manipulating the new version. I have read all kinds of material online and in printed books, and I just dont see it. I dont see resource saving, or "added protection". As I understand it, going A = B is the same thing as getting B, and setting it to A. Alot of the material I read even makes it sound like thats what the compiler does automatically, so whats the point of my typing extra lines?
Please help me figure this out.
Get/Set VS Copy and Manipulate?
-
Baal Cadar
- Posts: 377
- Joined: Fri Oct 28, 2005 10:28 am
- Contact:
Getter and Setter are good for many things. First, there doesn't always need to be an actual field A in an instance, if there is a getA and setA. A might as well be derived and computed. Second, even if there was a field A, using getters and setters the library programmer is free to change it in a future version without changing the interface, since all he/she needs to do, is to change the implementation of getA/setA to accomodate to an internal change. Resulting in a more stable API. Also with getA, setA you can have additional functionality over just reading and writing field A. For instance setA can test, if the value you want to meets certain requirements, or change it accordingly. If a function needs to set a colour channel value, the setter could clamp the components between 0 and 255, if the argument is outside this range.
There are a few more reasons, but these are the most important ones I can think of.
There are a few more reasons, but these are the most important ones I can think of.
-
pyromaniak
-
Baal Cadar
- Posts: 377
- Joined: Fri Oct 28, 2005 10:28 am
- Contact:
Well, now that you mention exception handling, it actually becomes more powerful a feature with getters/setters, as they can throw exceptions themself, if appropriate (like Java's IllegalArgumentException or InvalidStateException)
Anyway, by themselv Exception handling has nothing to do with this. In terms of object oriented design, getters/setters are a way to ensure encapsulation and information hiding. Information hiding means here, that the user of such a class does not know anything about its internal workings. It is controlled by its interface, which getters/setters are a part of. public fields don't hide anything. And later changes to the class are much more difficult, because a field change will then break the API and lead to many other changes throughout the code which uses this class. Getters/Setters prevent this to some degree.
There are even more design principles which are touched by getters/setters. Much more than can be handled in a forum post. Grap a text book on OO design and read up on it.
Anyway, by themselv Exception handling has nothing to do with this. In terms of object oriented design, getters/setters are a way to ensure encapsulation and information hiding. Information hiding means here, that the user of such a class does not know anything about its internal workings. It is controlled by its interface, which getters/setters are a part of. public fields don't hide anything. And later changes to the class are much more difficult, because a field change will then break the API and lead to many other changes throughout the code which uses this class. Getters/Setters prevent this to some degree.
There are even more design principles which are touched by getters/setters. Much more than can be handled in a forum post. Grap a text book on OO design and read up on it.