COM is an example of contract based OO. i.e. What IPersist is supposed to do, will never change, and if you implement IPersist, you're not suppose to do anything more than what IPersist requires.

quote:
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?

I think that would qualify as neurotic (class) behavior. You can get yourself into a situation where you need to use the public accessors if they invoke requesite side-effects (e.g. lazy evaluation). If the class that the data belongs too isn't even suppose to directly access it, maybe it shouldn't be part of that class, but another one?

In debug builds, accessors do have overhead - so if you use them on a very low-level in complex algorithms, you can impact the performance to the extent that you are unable to effectively run the program in a debug build (say you used them inside of an FFT algorithm and then called it continuously). Usually it's not a problem.

[edited by - Magmai Kai Holmlor on June 26, 2002 11:50:03 PM]

I use accessors but I also allow direct access. I''m leaning towards accessors though. One might do checks in the accessor function before returning the data to client. I do allow direct access to STL containers and other inner objects. I''ve also tried a new naming convention that I like especially using vc++6 ide in class view. I prepend my worker functions(non-public) with ''z_'' and structs with ''A_'' this way workers stay at the bottom on function list and structs stay at the top of all ''C'' prepended class names in class view. I have a clearer view of things this way. Global object data is ''m_'' prepended. It''s also clearer to me seeing I''m calling my workers rather than some win32/mfc code.