OP:
Get/set methods generally indicate that the variable you're trying to change should be in the class that's trying to change it
Better design has a class changing its own state in response to a message (call to one of its methods)...
But sometimes, methods that return simple data types are unavoidable. Classes that don't share information in some shape or form are pretty useless.
Public or Private?
Quote:Original post by WavarianYeah, you can do that and throw away all the real benefits of getter/setter methods.
I don't recommend making your class variables public, but you can make life a little easier for yourself if you define some of your getter/setter methods like this instead:
Quote:The problem with just out-right making your class variables public is that if you then decide to change the name of the variable, you'll have to change it everywhere else in your code.That's the only advantage your method has over public member variables, and I'd say it is a worthless benefit.
Quote:Also, if you want to make the class do something when the health variable is accessed, that goes out the window too by making everything public.So it does with your method. Nothing prevents the user of the class of calling Health() just once and then using the returned reference for access/modifications ever after. Your method also won't allow any verifications or calculations to be made when the value of the variable is changed.
The whole public/private/protected thing is imo a total waste of time. It only spreads confusion. I just make all public. Free world, you know. :)
Quote:Original post by Marmin
The whole public/private/protected thing is imo a total waste of time. It only spreads confusion. I just make all public. Free world, you know. :)
It may resolve confusion for the person designing the system, but the poor people who actually have to use the thing later will appreciate the many functions they don't have to interact with to be marked as such. There's a public interface, which is the link between your class and external objects, there's the protected interface, which is the interface between a base class and its child, and then there's private members, which are internal to a class. Using them all correctly helps other people interact correctly with your system, simplifies maintenance, and helps you to judge and contain the effects of changes later on.
Members that can be changed in such a way as to break the object should be protected by only allowing controlled access. Members that can be changed in any way and have no negative impact on the behaviour of the object can be made public.
A 3D vector, for instance, has three components: x, y, and z. They are in no way interdependent, and as such are good candidates for public access (a struct IMO, as the object has no invariants). Now consider a specialized NormalVector. The invariant for this object is that the length should always be 1, and all clients of NormalVector are guaranteed that this will always be the case. As such, the components of the vector should be private, and the interface should provide functions like PointAt(x,y,z).
My two cents [grin]
A 3D vector, for instance, has three components: x, y, and z. They are in no way interdependent, and as such are good candidates for public access (a struct IMO, as the object has no invariants). Now consider a specialized NormalVector. The invariant for this object is that the length should always be 1, and all clients of NormalVector are guaranteed that this will always be the case. As such, the components of the vector should be private, and the interface should provide functions like PointAt(x,y,z).
My two cents [grin]
Directly corresponding get/set is often a sign of bad programming, but the line between that and good programming is often very thin.
For example:
If you have an array, you don't want to expose a get_size and set_size function which merely modify the variable "size" which is keeping track of the size of your data - this could be used to make the size incorrect and not correspond directly to the actual data allocated.
However (assuming the array is a dynamic array like std::vector) DO want to provide functions that resize the array - with std::vector these are size() and resize(). Size is provided so that size can be implemented as a "read only" attribute, and resize, while modifying the size variable, also resizes the data allocated. It's the difference between exposing an implementation detail and exposing an interface.
There are also many times when public data is appropriate. If I have a 3d point, does it make sense to make x,y, and z all private? I'd say no. Some people would say yes, so you can attach actions to the setting of x/y/z - I'd argue anyone trying to do this is a bit crazy.
Also, it makes absolutely no sense to return a non-const reference to a private/protected member variable. Doing so provides no benifit over simply having the variable public in 99% of all cases. If you're doing this, it's a nearly surefire sign that you're doing something wrong.
[Edited by - MaulingMonkey on July 21, 2005 9:34:22 PM]
For example:
If you have an array, you don't want to expose a get_size and set_size function which merely modify the variable "size" which is keeping track of the size of your data - this could be used to make the size incorrect and not correspond directly to the actual data allocated.
However (assuming the array is a dynamic array like std::vector) DO want to provide functions that resize the array - with std::vector these are size() and resize(). Size is provided so that size can be implemented as a "read only" attribute, and resize, while modifying the size variable, also resizes the data allocated. It's the difference between exposing an implementation detail and exposing an interface.
There are also many times when public data is appropriate. If I have a 3d point, does it make sense to make x,y, and z all private? I'd say no. Some people would say yes, so you can attach actions to the setting of x/y/z - I'd argue anyone trying to do this is a bit crazy.
Also, it makes absolutely no sense to return a non-const reference to a private/protected member variable. Doing so provides no benifit over simply having the variable public in 99% of all cases. If you're doing this, it's a nearly surefire sign that you're doing something wrong.
[Edited by - MaulingMonkey on July 21, 2005 9:34:22 PM]
Quote:Original post by Anonymous PosterQuote:Original post by WavarianYeah, you can do that and throw away all the real benefits of getter/setter methods.
I don't recommend making your class variables public, but you can make life a little easier for yourself if you define some of your getter/setter methods like this instead:Quote:The problem with just out-right making your class variables public is that if you then decide to change the name of the variable, you'll have to change it everywhere else in your code.That's the only advantage your method has over public member variables, and I'd say it is a worthless benefit.Quote:Also, if you want to make the class do something when the health variable is accessed, that goes out the window too by making everything public.So it does with your method. Nothing prevents the user of the class of calling Health() just once and then using the returned reference for access/modifications ever after. Your method also won't allow any verifications or calculations to be made when the value of the variable is changed.
Please don't mis-interpret my post. My "method" and following words of advice were not related in any way. I attempted to cover all bases with the information provided by the OP. If he had a whole load of variables such as health, armor, etc and he found it to be annoying to have to type GetHealth() and SetHealth() with no other intention of doing anything inside the method itself, then my "method" would perhaps be a little cleaner.
Quote:Original post by WavarianPlease don't write your posts in such a way that can be easily misinterpreted. You should've stated that the main disadvantages apply to your "method" as well, not just public member variables.
Please don't mis-interpret my post.
Quote:My "method" and following words of advice were not related in any way. I attempted to cover all bases with the information provided by the OP. If he had a whole load of variables such as health, armor, etc and he found it to be annoying to have to type GetHealth() and SetHealth() with no other intention of doing anything inside the method itself, then my "method" would perhaps be a little cleaner.Why do you oppose public member variables then, and propose this "method" instead? It clearly has no meaninful advantages over public variables, but it has disadvantages as forcing one to write more code. I can't see how
class Player{ int m_health;public: Player() : m_health(0) { } int& Health() { return m_health; } const int& Health() const { return m_health; }};Player player;player.Health() = 100;int health = player.Health();is cleaner than
class Player{public: int Health; Player() : Health(0) { }};Player player;player.Health = 100;int health = player.Health;All I'm saying is that your "method" is worthless :p
Quote:Original post by Anonymous PosterAll I'm saying is that your "method" is worthless :p
I actually agree here, either you have a dumb data holder where (all) data is public it's just a convinent container of sorts most mathematicl vector classes ought to fall into this category as do many low level and convinence classes or in the other case you got something that's rightfully a class with behaviour and as such you have no buisness exposing your private parts publicly (good advice in many states no matter how you see it).
So either you should have it public and it should be safe as such or it should be encapsulated and if you're just typing exessive getters/setters you should look into your design and ponder some alternatives.
I really see the advantages of posting anonymously. Not only are you able to cut down anyone you see fit, but you can also rate them down on the side.
Real mature. I see no point in discussing this further, one of the very few times I come out to help someone, and I get hit over the head for shedding some light on another way to go about doing something. I doubt that I'm the only one who now only reads these forums instead of helping others.
You can go back to your lounge forum now.
Real mature. I see no point in discussing this further, one of the very few times I come out to help someone, and I get hit over the head for shedding some light on another way to go about doing something. I doubt that I'm the only one who now only reads these forums instead of helping others.
You can go back to your lounge forum now.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
