Hello all!
I've been lurking these forums for a while and finally decided to join up and be a real member of the community. I figured I'd introduce myself by asking everyone a simple question. When writing in an object oriented language, do you write a "getter" and "setter" method for every attribute of an object? What if you never intend to change the value of said attribute?
As an example: I'm working on my first game, a clone of pong. my class Ball has an attribute named size. Obviously the size of the ball in a game of pong never changes, but it felt strange to not write a setSize() method. Now I have code in my program that will never be used - and that feels a little strange too.
I know that there is no right or wrong answer to this question, I'm just interested in your individual opinions. Take it easy,
-Will
"Getters" and "Setters" - do you write them if you don't need them?
If it doesn't vary, it's not a variable. It's a constant.
const float Size = whatever.whateverf; //
Why write a function for something that's never going to change? While this may not occur much in the home-brew & hobby-est areas, I feel that you're adding the ability to mess with your game. You're just asking someone to abuse a function that was never meant to be used.
I have 10 fingers. That's not going to change. There is no standard function for me to remove a finger. If people are going to 'hack' away at me to attempt to remove said finger(s); I"m going to make them work [hard] for it.
Sorry if this reads weird - I have a bloody headache. :/
I have 10 fingers. That's not going to change. There is no standard function for me to remove a finger. If people are going to 'hack' away at me to attempt to remove said finger(s); I"m going to make them work [hard] for it.
Sorry if this reads weird - I have a bloody headache. :/
"Getters" and "Setters" are an interface to the data contained in your class. It is typically good practice to do this when you allow data in the class to be accessed externally.
For instance if you had a variable in your Ball class named "speed", you may want to increase this as the game goes on longer. This would require a setter because the game needs to externally increase it. Then lets say you would like to check to see if the ball is off screen. This would require a getter for the position to figure out where the ball is.
Of course you could make the data public in the class but this is considered bad style and should be avoided except when absolutley necessary.
If it is only used in the class and never changed outside the class it should not have a getter or setter.
Hope this helps.
For instance if you had a variable in your Ball class named "speed", you may want to increase this as the game goes on longer. This would require a setter because the game needs to externally increase it. Then lets say you would like to check to see if the ball is off screen. This would require a getter for the position to figure out where the ball is.
Of course you could make the data public in the class but this is considered bad style and should be avoided except when absolutley necessary.
If it is only used in the class and never changed outside the class it should not have a getter or setter.
Hope this helps.
A well designed class should have very few "reasons to change". If you've got a class with 100 different functions that change it's state in different ways, then that's a sign that your class can probably be broken up into many smaller classes. See SRP.
If you do have a class that needs to have a lot of accessible/modifiable attributes, consider just using a struct with public data members and no functions.
If you do have a class that needs to have a lot of accessible/modifiable attributes, consider just using a struct with public data members and no functions.
If you're writing software using object-oriented techniques, you rarely need getters and setters. Conversely, if you have a lot of getters and setters, you're not using object-oriented techniques, you're doing structured procedural programming. Don't fool yourself that because you use the 'class' keyword you're necessarily doing anything object-oriented.
An object-oriented ball doesn't ever need something else to tell it what its size is. Nothing else needs to know its size. It knows how to collide with walls and paddles. It knows how to draw itself.
An object-oriented ball doesn't ever need something else to tell it what its size is. Nothing else needs to know its size. It knows how to collide with walls and paddles. It knows how to draw itself.
Author
Why write a function for something that's never going to change? While this may not occur much in the home-brew & hobby-est areas, I feel that you're adding the ability to mess with your game. You're just asking someone to abuse a function that was never meant to be used.
I guess I just have this little voice in the back of my head that says "Hey, you might want to have control over that some day... better write a set function for it"
Sorry if this reads weird - I have a bloody headache. :/
Hope your head feels better!
"Getters" and "Setters" are an interface to the data contained in your class. It is typically good practice to do this when you allow data in the class to be accessed externally.
For instance if you had a variable in your Ball class named "speed", you may want to increase this as the game goes on longer. This would require a setter because the game needs to externally increase it. Then lets say you would like to check to see if the ball is off screen. This would require a getter for the position to figure out where the ball is.
Of course you could make the data public in the class but this is considered bad style and should be avoided except when absolutley necessary.
If it is only used in the class and never changed outside the class it should not have a getter or setter.
Hope this helps.
I does! I appreciate everyone's opinion on the subject.
If you do have a class that needs to have a lot of accessible/modifiable attributes, consider just using a struct with public data members and no functions.
Are structs still around? I know that you can *technically* use them in C++ but I've never seen them called for in any C++ book I have, and tbh I have NEVER seen a struct used in Java - the language I have the most experience in (which is not saying much).
Thanks for all the great insights everyone, keep them coming!
Author
If you're writing software using object-oriented techniques, you rarely need getters and setters. Conversely, if you have a lot of getters and setters, you're not using object-oriented techniques, you're doing structured procedural programming. Don't fool yourself that because you use the 'class' keyword you're necessarily doing anything object-oriented.
An object-oriented ball doesn't ever need something else to tell it what its size is. Nothing else needs to know its size. It knows how to collide with walls and paddles. It knows how to draw itself.
I really like the way you stated that. I guess I have some thinking to do about the way my "objects" handle themselves.
Structs are still alive and well, even in C++.
It just depends on what you are doing. In java there is no such thing as a struct. A class is the closest thing you have in java.
Structs are usually used for packing data at a lower cost than classes in most cases. This is why they are usually seen in lower level programming such as embedded systems In C++ the struct is deceptively similar to classes but there are some very important and distinct differences. Look here.
It just depends on what you are doing. In java there is no such thing as a struct. A class is the closest thing you have in java.
Structs are usually used for packing data at a lower cost than classes in most cases. This is why they are usually seen in lower level programming such as embedded systems In C++ the struct is deceptively similar to classes but there are some very important and distinct differences. Look here.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
