Get/Set functions: Like 'em?
Author
So the question on my mind is about Get and Set functions in a class.
What do you prefer: to have protected (or private) members that can be accessed via get/set functions in the class, or to have members that would be modified by these function directly exposed?
It seems to me that the get/set method is more object-oriented, as it uses implementation hiding. But, is it slower? I mean, it seems like it would have to be slower, but does it really make a difference?
So the questions are these: Which method do you prefer? Why? Is the get/set notably slower? I mean, enough to care about?
---
As for me, I like the get/set method, because it is more structured and more OO. However, since I lack a formal education in programming (I've done it for a good while, but it's been informal, so I miss things here or there. I start college - which hopefully will remedy this - in a week.) I don't know if it is notably slower, which could possibly sway my opinion.
It really depends.
For a while, I was using get/set methods on everything, because it was more OO. For simple things like vectors, I now prefer use direct access to the value because doing it with all get/set slows down debug builds. I still use get/set on almost everything else.
For a while, I was using get/set methods on everything, because it was more OO. For simple things like vectors, I now prefer use direct access to the value because doing it with all get/set slows down debug builds. I still use get/set on almost everything else.
It's a false dichotomy. If you find yourself trying to decide whether you should have getters and setters or simply public variables, you aren't really doing OO design.
An object's linkage to the world is not its state (public variables), but its messages (public functions). That should be the first consideration when designing a class. What private class data is actually needed is a later design step.
Any public class member function that is designed to be called by another object should take the form of a message. It is something that the other object is SAYING to this object. It could be a statement, or a question, or a command. Making member variables public utterly subverts this paradigm. Suppose that instead of telling someone "your employee ID is now 19231" you SAWED OPEN THEIR SKULL and rewired their neurons so that the employee ID they remembered was 19231. Limitations of neurosurgery aside, this method requires you to know much more about the class than you'd like, it doesn't allow the class to do any of its own checking, and it makes things very difficult to modify later on. The only "advantage" is that if you're thinking of objects as structured data rather than autonomous entities it better fits your head. But then you shouldn't be thinking in terms of object-oriented design at all.
I can't count on my fingers the number of times a setter function HASN'T just been void SetFoo(int foo) { m_foo = foo; }. Derived private data, bounds checking, notification... the list goes on and on. There's just no good reason not to do things this way.
EDIT: I should point out, BTW, that there's no reason to make EVERYTHING in your program a hardcore OO class. I use inner structs quite a lot, for instance, and I don't know anyone who "talks" to their quaternion class. So perhaps the real answer is that the choice is not between getters/setters and public variables, but between classes and structures.
An object's linkage to the world is not its state (public variables), but its messages (public functions). That should be the first consideration when designing a class. What private class data is actually needed is a later design step.
Any public class member function that is designed to be called by another object should take the form of a message. It is something that the other object is SAYING to this object. It could be a statement, or a question, or a command. Making member variables public utterly subverts this paradigm. Suppose that instead of telling someone "your employee ID is now 19231" you SAWED OPEN THEIR SKULL and rewired their neurons so that the employee ID they remembered was 19231. Limitations of neurosurgery aside, this method requires you to know much more about the class than you'd like, it doesn't allow the class to do any of its own checking, and it makes things very difficult to modify later on. The only "advantage" is that if you're thinking of objects as structured data rather than autonomous entities it better fits your head. But then you shouldn't be thinking in terms of object-oriented design at all.
I can't count on my fingers the number of times a setter function HASN'T just been void SetFoo(int foo) { m_foo = foo; }. Derived private data, bounds checking, notification... the list goes on and on. There's just no good reason not to do things this way.
EDIT: I should point out, BTW, that there's no reason to make EVERYTHING in your program a hardcore OO class. I use inner structs quite a lot, for instance, and I don't know anyone who "talks" to their quaternion class. So perhaps the real answer is that the choice is not between getters/setters and public variables, but between classes and structures.
Providing accessors and mutators for each and every (or even just 'most') private variable is stupid, as it encourages direct manipulation of the object's state. Defining operations on the object is much better: even though it is just a name change, MoveTo(x,y) is superior to SetXY(x,y), as it defines an action on the object rather than emphasizing the modification of a data field. If your client code spends its time doing series of Get/Set on your object, then you are doing something wrong.
Furthermore, you'll notice that a lot of people will write accessors and mutators that are merely pass-through. There is little point to that, especially if you provide both pass-through accessor and mutator and have your client code rely on that fact. All you'd have done is to add a pair of parentheses to your member variable name.
If your class really is a behaviorless data structure, you might as well use a struct where everything is public. Encapsulation is a good thing when there are some properties of the class that you do not want to get arbitrarily changed. For example, a linked list class doesn't (shouln't!) directly let you access its nodes and their pointers, since careless manipulation would break the list. Instead, it provides operations on the list, such as appending, inserting, removing, splicing... which do modify all those pointers internally. But if your class is a 3D point, there is little reason to hide that data - it just makes using the class more awkward.
Speed is no concern - an inlined member function will be just as fast as a direct operation on the member variable ... particularly since you seem to be thinking about pass-through accessors/mutators. [rolleyes]
Furthermore, you'll notice that a lot of people will write accessors and mutators that are merely pass-through. There is little point to that, especially if you provide both pass-through accessor and mutator and have your client code rely on that fact. All you'd have done is to add a pair of parentheses to your member variable name.
If your class really is a behaviorless data structure, you might as well use a struct where everything is public. Encapsulation is a good thing when there are some properties of the class that you do not want to get arbitrarily changed. For example, a linked list class doesn't (shouln't!) directly let you access its nodes and their pointers, since careless manipulation would break the list. Instead, it provides operations on the list, such as appending, inserting, removing, splicing... which do modify all those pointers internally. But if your class is a 3D point, there is little reason to hide that data - it just makes using the class more awkward.
Speed is no concern - an inlined member function will be just as fast as a direct operation on the member variable ... particularly since you seem to be thinking about pass-through accessors/mutators. [rolleyes]
Author
Quote:Original post by Konfusius
See here [cool]
Great reference. Thanks.
Quote:Original post by skittleo
Using get/set method is no better than making the members public. If you are going for an absolute OO approach, then avoid get/set completely. It is simply a way for code to look OO when in reality it is hardly different than structural programming.
The way to avoid get/set is to design your classes to be self contained and modular. Why should an outside source need to directly change the properties of an object if that object is self managed? It shouldn't.
I have to disagree that get/set methods are just a facade. Like Sneftel said, so many things can go on in one of these methods that is not just retreival of data. And not ALL classes (in fact, in a program of any size, NO classes) are entirely self-contained. They have to have a way to interact with other classes, and controller classes have to have a way to control the classes they are responsible for. And, again, a get or set method is not just direct access, so outside sources are not directly modifying the properties of an object.
You are completely right, though, that classes should be, as much as possible, self-contained, and they should all be modular. This is the core of OO programming.
---
@Sneftel and Fruny:
I could not agree more with what you both said. I think the combination of your answers sums up the issue very well. Mutators and not Accessors are the way to go, except for purely behaviorless data, in which case, a struct is the way to go.
---
I just want to mention that the reason I asked is that I see so much code that just makes everyting publc. I was just wondering if there was something glaring that I had missed. I design all my code OO style (with occasional exceptions). So, it's not my design that I'm trying to figure out, it's making sure that a) I'm doing it right and b) I wasn't missing something.
[Edited by - ricekrispyw on August 16, 2005 12:47:00 PM]
Author
Quote:Original post by skittleo
Oops sorry. I think I did not correctly express my thoughts on the topic. I did not meant to imply that there be no outside communication with the class to control its operation. By self-contained, I meant the internal properties of the class are transparent to the caller.
For an example, imagine you have a game player object that you wish to move. Which would be a more OO approach- SetVelocity or a WalkRight? By calling WalkRight, you communicate your objectives to the object without ever having to understand the details of how the object works internally.
Either way, my feelings about the topic are the same as Fruny and Sneftel so if it seemed different, it was only because I did not express my thoughts accurately.
Gotcha.
In that case, I totally agree with you, too. Clearly, WalkRight is the better alternative.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
