virtual UINT GetWidth() const { return m_iWidth; }when to use accessor functions
Author
I have accessor functions for a class like this:
It somewhat depends. If you wanted to go with 100% strict object oriented programming encapsulation that you were taught about in school, then you would make functions for every variable. But, you can do it either way since there is no standard.
Author
I want to and have made accessor functions for every member variable. I was wondering if the accessor functions should be used by other member functions of the same class or just by external functions.
To be truly OO, you'd have the internal accesses go through the accessor just like the externals.
The reason to have accessor functions in the first place is for encapsulation. So, if you change GetWidth in the future to perform some action (like send a signal to some other object) in addition to just returning the variable, you will only need to make that change in one place, not all over the code.
Also, since you're making GetWidth virtual you are implicitly assuming it could be subclassed in the future, if that's the case you want the subclass to be able to modify what happens in the accessor, so if the internal accesses of the variable don't use the accessor, things can get confusing.
However, if GetWidth() is only ever going to return a simple variable, throw pure OO out the window and access it directly. In that case, even consider not even forcing externals to have to use the accessor and make the variable public. OO is a good design methodology but you shouldn't be afraid to bend or break the rules for practical purposes.
Edited by - gmcbay on December 17, 2001 7:46:06 PM
The reason to have accessor functions in the first place is for encapsulation. So, if you change GetWidth in the future to perform some action (like send a signal to some other object) in addition to just returning the variable, you will only need to make that change in one place, not all over the code.
Also, since you're making GetWidth virtual you are implicitly assuming it could be subclassed in the future, if that's the case you want the subclass to be able to modify what happens in the accessor, so if the internal accesses of the variable don't use the accessor, things can get confusing.
However, if GetWidth() is only ever going to return a simple variable, throw pure OO out the window and access it directly. In that case, even consider not even forcing externals to have to use the accessor and make the variable public. OO is a good design methodology but you shouldn't be afraid to bend or break the rules for practical purposes.
Edited by - gmcbay on December 17, 2001 7:46:06 PM
It''s not for encapsulation - it _might be considered a good data-hiding practice (though I generally challenge that).
A favorite hack of mine, is to make properties public and constant, and cast away the const''ness where appro. inside the class.
VC and BCB both provide compiler extentions to automatically call get/set tuples for accessing data (like VB and Delphi do), btw.
If you can drop the virtual it will compile with no overhead.
Internally I wouldn''t call that accessor function, might consider it for one with no overhead, but probably still wouldn''t call it - depends on what the accessor does.
Magmai Kai Holmlor
"Oh, like you''ve never written buggy code" - Lee
"What I see is a system that _could do anything - but currently does nothing !" - Anonymous CEO
A favorite hack of mine, is to make properties public and constant, and cast away the const''ness where appro. inside the class.
VC and BCB both provide compiler extentions to automatically call get/set tuples for accessing data (like VB and Delphi do), btw.
If you can drop the virtual it will compile with no overhead.
Internally I wouldn''t call that accessor function, might consider it for one with no overhead, but probably still wouldn''t call it - depends on what the accessor does.
Magmai Kai Holmlor
"Oh, like you''ve never written buggy code" - Lee
"What I see is a system that _could do anything - but currently does nothing !" - Anonymous CEO
Internally, you should not use the accessors. They are for external access the the private member varaibles. The main reason for not wanting to use them and make the member variables public is for speed. So if you are writing a game and find you need a speed increase, one of the first things you can do is get rid of all your accessor funcitons and make the member variables public.
---
Make it work.
Make it right.
Make it fast.
---
Make it work.
Make it right.
Make it fast.
quote:Original post by CaptainJester
Internally, you should not use the accessors.
Yes, you should. See gmcbays post.
quote:
So if you are writing a game and find you need a speed increase, one of the first things you can do is get rid of all your accessor funcitons and make the member variables public.
You do no such thing. Instead you run a profiler against your code and find where the bottlenecks are. I can almost guarantee you that it wont be the accessor functions.
Fantastic doctrines (like Christianity or Islam or Marxism or Microsoft-bashing) require unanimity of belief. One dissenter casts doubt on the creed of millions. Thus the fear and hate; thus the torture chamber, the iron stake, the gallows, the labor camp, the psychiatric ward - Edward Abbey
quote:Original post by Magmai Kai Holmlor
A favorite hack of mine, is to make properties public and constant, and cast away the const''ness where appro. inside the class.
I do not think that the compiler is required to allow the const_cast to work, but I guess that it is safe anyway.
It would be nice if you could do something like this:
class array{public: union members_type { public: struct exposed_type { const int size; const int* elements; } exposed; private: struct hidden_type { int size; int* elements; } hidden; members_type() {} friend array; } members; array(int size) { myarray.members.hidden.size = size; myarray.members.hidden.elements = new int[size]; } ~array() { delete[] myarray.members.hidden.elements; }private: array (array&); array& operator = (array&);};int main(){ array myarray(10); myarray.members.exposed.size = 20; // error: const myarray.members.hidden .size = 20; // error: private}...only without all the fuss.
I would still go with accessor functions, though.
Hi
You should use accessor functions with OOP, but the become really interesting in component oriented design (Java Beans, ...)
For example, this makes it possible to fire and receive events if data is changed => OnPropertyChanged methods ...
Have fun
Bunnz
Visit: Bunnz Productions
You should use accessor functions with OOP, but the become really interesting in component oriented design (Java Beans, ...)
For example, this makes it possible to fire and receive events if data is changed => OnPropertyChanged methods ...
Have fun
Bunnz
Visit: Bunnz Productions
I''ve found that using accessor functions help to ensure flexibility in your code.
During runtime, if there is some last-minute change you want to make to the variable before it is returned, you can in the accessor function.
----
Herb M. (mdfmKoRn)
s3202@attbi.com
During runtime, if there is some last-minute change you want to make to the variable before it is returned, you can in the accessor function.
----
Herb M. (mdfmKoRn)
s3202@attbi.com
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
