So, I think that putting stuff into the private scope is enough to “encapsulate” [imagine Doctor Evil type quotations]. I thought so, I honestly did, I mean it says private what more do I need?
But how private is private really?
Short answer, mostly private.
Long answer, potentially private, potentially having more letters than mostly.
But why, and when, isn’t private really private any more?
The first obstacle I’ve come across and one that has plagued me for a while now comes from my IDE [Visual Studio Express, an amazing environment for free]. Amazing in most but not in all. In a word, Intellisense. In a few more words, the fact that Intellisense will display every item within the class definition regardless of scope. It’s annoying and it’s cluttering and worse – it hides the public interface of the class. If I can’t call it, I don’t want to see it.
The second issue is a more serious one and is related to compilation dependencies and translation units. This mostly comes through the particular implementation of Class definitions as handled by C++ and the idea behind the private keyword.
A quick diversion. Private scope denotes internal state, an object’s interface should be separated from its internal state [though work together] and internal state [data and any helper functions internally related to managing this data] is more likely to change than external and public functionality.
Back to normal broadcasting services… C++ forces the internal state of an object to be represented within the same file/space as its interface, everything has to be declared in the same place. Couple this with the fact that internal state is more volatile and you end up with frequent recompilation of the public interface when just the internal [hidden] state has changed – not fun but far from life threatening.
I’ve come to terms with these issues, understood them and filed them under ‘oh well, nothing I can do, better deal with it’. That is a dangerous mind frame as it leads to blindness and the repression of growth. And if there is one thing I’ve come to understand about programming is this, if I stop learning new things then I’ll be left by the wayside.
On to the encore, the final note of this little talk, Users [including myself down the road].
In a perfect world people who use code will treat it with the same respect that the programmer gave it at the time. In a perfect world I would be rich and have my own spaceship and at least one magic button that can produce coffee. This, unfortunately, isn’t a perfect world and putting aside for a second the idea that if your things are private in a header file someone can just change the word to public, I’d like to welcome a new idea I’ve been presented with by the FQA [google it].
#define private public
Yup, it’s simple, it’s elegant and it killed any idea of data encapsulation that I had using normal classes.
I’m not afraid of losing the private scope, that’s not what this post has been about. Rather, it’s about opening my eyes and understanding the true meaning of internal state and object/interface separation. It’s about giving more thought to design decisions which would affect file/object dependencies and it’s about creating safer application environments for the future.
I’m working through on it, I’m sure I’m not the only one and I’m sure other programmers [with much more experience than me] have already found ways to solve this particular conundrum. If anyone is here other than me I would love to hear about your ideas and solutions, mine at the moment involves experimenting with header-based interfaces and source-based object implementations.
My next post would probably involve more work towards this and should also lay down some coding standards.
“And if you build your life on dreams, it’s prudent to recall, a man with moonlight in his hands… has nothing there at all”.