Bloating Code with Get/Sets

What is this code part of? A large project? Do you foresee that you will ever have to bounds-check?

[Edited by - Daniel Miller on December 23, 2004 11:43:11 PM]

Go for the public member variables. Get/Set is clunky in a lot of cases.

Big thanks for replies!!
No, this code is my starting point for game programming. It's just for kicks right now because they will not teach it at the business Colleg I attend. Anyways, public variables seem the way to go. I do not want to write 20 get/set methods if not needed.
If error-checking becomes needed as I expand or add-onto this game I will write as needed.

This is the subject of much heated debate and you'll get a fair amount on each side of the arguement.

For trivial structures (points and vectors being the classic examples), it's better to go with public members. Otherwise i recommend a proper interface. However, if every private data member has accessors, that could be a sign of bad design. Instead of...

// do damage the bad way
int new_health = badguy.GetHealth() - goodguy.GetDamageRating();
badguy.SetHealth( new_health );

it should look more like...

// do damage the better way
badguy.HurtMe( goodguy.GetDamageRating() );

or even...

goodguy.Attack( badguy );

The point is that you shouldn't have to open up all the private variables and go mucking around in there. It's private for a reason.

There is a lot of info on this forum and elsewhere. Read up for lots more +/- on the subject

For a small project where you don't think that you will have to bounds check, just do exactly as you thought: use public member variables. It isn't worth the time (or decreased readability) to hide everything behind getters and setters.

It's often bad to access internal representation all the time, and is much better to make methods that minimize it, like leiavoia said.
"public members" isn't bad by itself, but inproper use of low-level class things outside of class is often bad.

In any case, you can easily enough add get/set functionality once it will be needed. Just make members be private or protected, and fix every compiler error you'll get by adding get/set and using get/set.

A search for 'get set' or 'public private' will probably turn up all the arguments for either side that you will ever need. However, I can't resist throwing in my $.02!

My advice: start learning proper object-oriented techniques now, even if your project is too small or simple to really benefit from them. Once you find yourself designing large, complex systems, you will start to see the benefits.

My own rule is that anything that has behavior is a class with all member data private. If something is truly just a 'bunch of data' with no behavior, I make it a struct with public data.

One of the ideas behind private data is that the 'outside world' has as little to do with it directly as possible. As the other poster suggested, you should think about object 'behaviors' rather than thinking about poking around at the data directly. If you have getters and setters for every private variable, you're sort of defeating the purpose.

In my engine all class data is private - even stuff like Vector and Matrix classes. Overkill? Perhaps. But I have found myself considering different internal implementations of the above classes, and if I chose to do so, thanks to the private data and public interface, not one line of code outside of those classes would need to change. That's one of the beauties of object oriented design.

All IMHO, of course.

But making things too complicated for the sake of his future programs could make it so he never finished anything. It helps to have something finished to motivate you.

hmm, vector class with methods GetX GetY GetZ and SetX SetY SetZ ?

(But, for matrix it really makes some sense to either overload operator() or make member "at" .)
It doesn't really take longer to swich to get&set once you'll need 'em than to write get&set since beginning. Just move all members to "private" section, and then fix every compiler error.

Quote:

Original post by Anonymous Poster I'm going to get flammed to buggery and back for this, but what the hell, it's chistmas! Step 1: Write code however-the-hell you feel like. Throw caution to the wind, ignore so called 'best practices', make up a new style with each project. Step 2: Get bitten in the ass by the screwy choices you made in Step 1. Step 3: Come up with your own way to not get bitten in the ass the next time you're in that situation. It may or may not be similar to an existing 'best practice' Step 4: Congratulations, now you have your own 'best practice' and since you reached the conclusions on your own, you can use your own judgment to make choices about using whatever design pattern, style, 'getters/setters or not' and so on without just doing things a certain way just because a book/person on the net/whatever told you to. Fuck up early and often. You'll learn _SO_ much more digging yourself out of holes than you ever will just following instructions... but that's just my opinion, i'm sure plenty of people will disagree.

(not meant to be sarcastic, in case anyone is wondering; not only will you learn better ways of doing things this way, you'll also learn a lot about how to find problems and how to fix them, which is an absolutely vital skill)

John B

I'm with you AP - too many people are afraid of ever making a mistake - but you can guarantee that you'll remember better when you do.

It's only coding, not brain surgery (in which case this advice may not hold...)

And a merry anonymous christmas to you too!
Jim.

Quote:

hmm, vector class with methods GetX GetY GetZ and SetX SetY SetZ?

Actually, it's overloaded [], but I have seen commercial libraries with named accessors. Usually though it's just X() rather than GetX().

In any case, this is one of those things that's probably pointless to argue about :-)

Quote:

Original post by jyk Quote: hmm, vector class with methods GetX GetY GetZ and SetX SetY SetZ? Actually, it's overloaded [], but I have seen commercial libraries with named accessors. Usually though it's just X() rather than GetX(). In any case, this is one of those things that's probably pointless to argue about :-)

of course.
But can you elaborate bit more about X() ?
Is it double &X(); ?
I think such reference-returning things serve no purprose / is practically no different to public members.

Quote:

Original post by Anonymous Poster I'm going to get flammed to buggery and back for this, but what the hell, it's chistmas! Step 1: Write code however-the-hell you feel like. Throw caution to the wind, ignore so called 'best practices', make up a new style with each project. Step 2: Get bitten in the ass by the screwy choices you made in Step 1. Step 3: Come up with your own way to not get bitten in the ass the next time you're in that situation. It may or may not be similar to an existing 'best practice' Step 4: Congratulations, now you have your own 'best practice' and since you reached the conclusions on your own, you can use your own judgment to make choices about using whatever design pattern, style, 'getters/setters or not' and so on without just doing things a certain way just because a book/person on the net/whatever told you to. Fuck up early and often. You'll learn _SO_ much more digging yourself out of holes than you ever will just following instructions... but that's just my opinion, i'm sure plenty of people will disagree.

i agree.
The only somewhat realistic alternative is much worse, something like
Step 1: write the code prematurely truing hard to do best practices....
Step 2: never complete it, or get bitten in the ass. There's no way to use best practices without knowing real reasons behind 'em and where to use 'em.
Step 3: write code especially avoiding best practices (being scared very much by step 2)
Step 4: get bitten in the ass second time.
and only at step 6 do something good.

Quote:

Is it double &X(); ? I think such reference-returning things serve no purprose / is practically no different to public members.

No, no references are returned. As you say, that would be pointless - might as well just make them public at that point.

In any case, I realize I'm in the minority as far as private vector data goes - the majority of vector classes I've seen just keep their data public.

Quote:

Original post by JohnBSmall (not meant to be sarcastic, in case anyone is wondering; not only will you learn better ways of doing things this way, you'll also learn a lot about how to find problems and how to fix them, which is an absolutely vital skill) John B

Indeed. My point of posting in this forum is basically to forsee all the opinions of the tried-and-true developing techniques before I go ahead and waste 20 hours becuase I missed an obvious point in the concept at hand (which I do sometimes!!). Anyways, THANK YOU ALL FOR POSTING!!
I have chosen to write them all as public data members, because:
1. I can port my old code over easier
2. No bounds-checking... yet!!
3. Easy as pie to write get/set later on.

Thank you all. A few opinions have helped me to realize the point of these trivial methods!!