Damjan "Rhuantavan" Mozetic
http://users.volja.net/mozeticd/
Accessor methods in C++ classes
Author
I was wondering if I should create accessor methods for all my private/protected variables and use those instead of variables directly. I really don''t know how far should I get with these. Eventually I would make the accessors inline, so there would be no speed penality, but I am still confused on how often and where to use accessor methods. Maybe I should only create accessor methods for the variables I want to give public access to the class user?
Please clarify this mess for me
Damjan "Rhuantavan" Mozetic
http://users.volja.net/mozeticd/
Damjan "Rhuantavan" Mozetic
http://users.volja.net/mozeticd/
Well, if you want to be purely OO then you make all of your variables private and provide protected and public accessor methods for both reading and writing for those variables that you want exposed to the outside world.
i see that as a bit overkill though, i mostly use accessors for variables i want read/write access inside the class and read-only access outside the class. i.e. i make the variable private and provide an accessor that returns a const reference.
i see that as a bit overkill though, i mostly use accessors for variables i want read/write access inside the class and read-only access outside the class. i.e. i make the variable private and provide an accessor that returns a const reference.
Author
Thanks for the reply. I still don''t know if that is really too much of an overkill...
by providing accessors for everything you only want available as read-only, it makes sure that the class is used the way it was intented, making it a better design than something that allows dodgy hacks of variables ''internal'' to the class. so for that reason i''d say it definitely isn''t overkill.
as for providing accessors for everything....it really depends on how much you think the internal structure of the class could change. Take a Rect class for example
now say you''ve got a whole bunch of code that uses this, and for whatever reason you want to change the Rect class to be stored using width&height instead. no problems, change your variables to float x,y,w,h and your accessor functions. no changes are needed to code outside of the class. if you were accessing variables directly though.....well, that would be one pain in the ass
and before ne1 says it....yes a rectangle is a crappy example, but it demonstrates the idea, and it''s the first thing that came to mind
so if the class is used a lot and you''re expecting internal changes in the future, go for it...give all variables you want public/protected accessors. but if not, why bother?
as for providing accessors for everything....it really depends on how much you think the internal structure of the class could change. Take a Rect class for example
class Rect { float t,l,b,r;public: float GetTop(void) { return t; } float GetLeft(void) { return l; } float GetBottom(void) { return b; } float GetRight(void) { return r; } float GetWidth(void) { return r-l; } float GetHeight(void) { return b-t; } // equivilent Set* members....}; now say you''ve got a whole bunch of code that uses this, and for whatever reason you want to change the Rect class to be stored using width&height instead. no problems, change your variables to float x,y,w,h and your accessor functions. no changes are needed to code outside of the class. if you were accessing variables directly though.....well, that would be one pain in the ass
and before ne1 says it....yes a rectangle is a crappy example, but it demonstrates the idea, and it''s the first thing that came to mind
so if the class is used a lot and you''re expecting internal changes in the future, go for it...give all variables you want public/protected accessors. but if not, why bother?
Author
You'r right, thanks
And another thing. How about decorating private vabiables with a leading underscore? Bruce Eckel in his Thinking in C++ book says you should not use leading underscores because they are reserved. Still I've seen some people use it. I think it really gives a clear picture of what's private and what's not.
[edited by - Rhuantavan on June 23, 2002 7:05:07 AM]
And another thing. How about decorating private vabiables with a leading underscore? Bruce Eckel in his Thinking in C++ book says you should not use leading underscores because they are reserved. Still I've seen some people use it. I think it really gives a clear picture of what's private and what's not.
[edited by - Rhuantavan on June 23, 2002 7:05:07 AM]
quote:Original post by Rhuantavan
You'r right, thanks
And another thing. How about decorating private vabiables with a leading underscore? Bruce Eckel in his Thinking in C++ book says you should not use leading underscores because they are reserved. Still I've seen some people use it. I think it really gives a clear picture of what's private and what's not.
[edited by - Rhuantavan on June 23, 2002 7:05:07 AM]
Bruce Eckel is correct. Leading underscores are reserved for compiler writers and it is a bad idea to start any identifier with an underscore. An alternative that doesn't require too much more typing is the Hungarian notation method of prefixing member variables with 'm_'. I find that having a variable with a name like m_width makes it stand out quite obviously as a member variable. Along those same lines, Hungarian notation recommends g_ for globals instead of some other convention like all capitals.
[edited by - jaxson on June 23, 2002 11:25:34 PM]
The most pressing reason to use accessors, at least IMO for what it's worth, is syntaxic uniformity. It's easier to use (template-based) functional adaptors with methods than with properies. For this reason, if you do make a property public, it's not a bad idea to add accessors for those properties as well. It would be easier to use std:
air with conditional algorithms (i.e. searches) if there were two methods called first() & second() that returned references to the underlying data elements.
The most pressing reason not to use accessors is because it's a waste of time. It abstracts nothing, and therefore accomplishs no work. If it _does_ abstract something, it shouldn't be an accessor, it ought to be a 'normal' method with a more descriptive name.
...
An alternative to HN, is to use language constructs to signify the scope of the variables and rely on the compiler for type checking. It requires a little more due-diligence, but after trying it I like this method better.
No decoration would indicate a local. I decided that distinguishing between 'true' locals & function parameters is more bother than it's worth.
...
Technically I think you're allowed to use a preceeding underscore on properties (and variables inside of a namespace), so long as they do not start with a capitol letter (I think, ...might have that backwards [edit, I had it backwards, fixed]).
[edited by - Magmai Kai Holmlor on June 26, 2002 1:33:43 AM]
air with conditional algorithms (i.e. searches) if there were two methods called first() & second() that returned references to the underlying data elements.The most pressing reason not to use accessors is because it's a waste of time. It abstracts nothing, and therefore accomplishs no work. If it _does_ abstract something, it shouldn't be an accessor, it ought to be a 'normal' method with a more descriptive name.
...
An alternative to HN, is to use language constructs to signify the scope of the variables and rely on the compiler for type checking. It requires a little more due-diligence, but after trying it I like this method better.
CClass::Method(){//Explicit use of this-> clearly indicates it's a property//Same goes for methodsthis->property = 0;//Scope accessor :: clearly indicates global scope::global_hole } No decoration would indicate a local. I decided that distinguishing between 'true' locals & function parameters is more bother than it's worth.
...
Technically I think you're allowed to use a preceeding underscore on properties (and variables inside of a namespace), so long as they do not start with a capitol letter (I think, ...might have that backwards [edit, I had it backwards, fixed]).
[edited by - Magmai Kai Holmlor on June 26, 2002 1:33:43 AM]
Author
I am reluctant to the use of hungarian notation... maybe because it reminds me of microsoft
I use the scope resolution operator :: for globals, but I''ve been using the leading underscore for my private and protected variables and until now had no problems. I''ve seen the underscore usage in Gamma, Helm, Johnson & Vlisside''s Design Patterns book with the samples in C++, so I thought their usage appropriate for myself.
Concerning accessors, I think I''ll use them all over. Another thing. Do you use the accessors to get private variables even inside private methods, or do you refer to the variables directly when going "deeper" into the implementation of the classes? Am I complicated? Sometimes I think I am...
I use the scope resolution operator :: for globals, but I''ve been using the leading underscore for my private and protected variables and until now had no problems. I''ve seen the underscore usage in Gamma, Helm, Johnson & Vlisside''s Design Patterns book with the samples in C++, so I thought their usage appropriate for myself.
Concerning accessors, I think I''ll use them all over. Another thing. Do you use the accessors to get private variables even inside private methods, or do you refer to the variables directly when going "deeper" into the implementation of the classes? Am I complicated? Sometimes I think I am...
Read the excellent CUJ article[1] by Herb Sutter and Jim Hyslop on the subject.
It abstracts the internal representation of that data in the class, which is the whole point. You too would benefit from that article.
[1]http://www.cuj.com/experts/1902/hyslop.htm?topic=experts
quote:
It abstracts nothing, and therefore accomplishs no work.
It abstracts the internal representation of that data in the class, which is the whole point. You too would benefit from that article.
[1]http://www.cuj.com/experts/1902/hyslop.htm?topic=experts
Get/Set accessors fail to abstract the internal representation - at best they mis-represent it. We''ve had this discussion many times now, I don''t expect you to change your mind.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
