class

[Amon Ra]

i have a class with quite a few members..i was wondering if i should create "reader/writer" functions, or simply make the member variables public? i thought it would be more organized to have the accessors, but i am not sure..any advices?
thanks

[Amon Ra]

would ther be some way of creating let/get properties?
thanks

[Destined Soul]

Originally posted by Amon Ra
would ther be some way of creating let/get properties?
thanks

Not that I'm aware of myself. As far as I know, if you call: "object.x = 3.0;" I think it will look for a non-private member variable (double x;)

I really wish that they would put this in, though. When I first learned that VB had such a function, I was incredibly surprised. It sure beats "double GetX()" and "void SetX(double Val)"

Oh, as for the read/write functions, it's usually a good habit. My rule is that if I only just set/check the value of it without having to do any math to it. Otherwise, I usually put it into a function. That way if any other math is always done to the variable x, you know that it's the function "SetX(..)" that's going wrong and not the code that calls it.

Well, you get the idea. I guess the proper way to think of it is to make the class completely idiot-proof, even if you're the one using that class. Ever make a textbox that inputs ONLY numbers, ensuring that if anything else is entered, an error occurs? If so, you should have an idea...

Anyhow, as usual, I'm starting to babble... :p

Destined

[kedaman]

Property Get&Let/Set produce the illusion of direct access to a variable. Mistaken this, a big source of bugs is when you try to modify a variable that has been retrieved with Property Get.

Encapsulation is a important issue, depending on how much exposed your class is meaning you estimate the range of use of it, the more reason there is to keep proper encapsulation, protect data and defy assertions. Ideally you would follow this rule at all cost but in practice you will be producing layers and loose the encapsulation and protection within certain bounds. At times you also have to make compromises between runtime speed and the OOP paradigm, but that you shouldn't do without being certain about the results. Regularily you compromise between OOP and design time.

[Amon Ra]

yea basically my class is a bit lik ethis:


class CLASS {
private:
int a;
long c;
char *b;

public:
int geta() {return a;}
void seta(int val) {a=val;}
....
}


you see nothing special is happening to these variables, but i thought it still looks more organized, and clean...it is quite a bit longer, but i'll keep it that way anyways..
thanks for the advices =)

[parksie]

But what's the point of doing that? The idea of hiding your member variables is to hide the implementation details - for example your class's users shouldn't need to know that you use a float, a string, and an int* (for example), so making them private and using get/set functions for them all is worthless.

[Amon Ra]

so they should just be public?

[parksie]

Well, if all you're going to do is make get and set functions for them all, then basically yes :)

However...if you need to verify the new values then you can use get/set - it's not bad as such to use them, but it *is* bad to use them for everything, making a data-access interface rather than an "action" interface.

[kedaman]

Aha, parksie here again, trying to sneak in and undermine encapsulation! Don't listen to him, because he talks bullcrap :p

Since you are not experienced with object orientation in general, you should practice on it by using get/set methods. In case you are working with a small project, or just playing around or testing something, then it's ok, but by practicing encapsulation you learn the meaning of it.

[parksie]

Do I? ;) :p :D

This could get amusing...nobody can actually win this discussion so I'm gonna be militant about my opinion, and I'd expect no less from Mr. Sugii :eek:

As far as practice goes, that's ok, but OOP design recommendations say that you shouldn't expose your implementation in a way that might make your users dependent on that implementation. And if that sounds heavy and incredibly complicated, that's because it is but then again this is C++ - sanity when you've finished learning it (if you ever do) is not guaranteed.

I mean, just look at what happened to me :p

[Amon Ra]

so kedaman, should i keep my accessors?

[Amon Ra]

i would have a very large amount of code for these accessors if i do keep them..

[parksie]

Inlining helps here:class X {
public:
inline int GetVar() { return m_iVar; }
inline void SetVar(int iVar) { m_iVar = iVar; }

protected:
int m_iVar;
};

[Amon Ra]

i have quite a few members though..like 10..

[parksie]

Sorry, no alternative to it - you have to code all the functions up.

Actually, if you're using MSVC++ then you can use a __declspec on it, but that's nonstandard.

[Amon Ra]

ok thanks..btw i do have msvc++, but it wont hurt me to write a few more lines of code...=)
thanks