Alright, I’m on item #30, so I’m more than half way through the book. It’s REALLY easy read. Nothing too complicated or mind bending here. But it’s tremendously helpful, a very nice review, and reminder of c++’s ‘complications.’
I will come back to talk about this more tomorrow.
A few things before I go:
* Member variables all private:
Hmm, once a ‘guru’ c++ guy that I worked with said this: “What the hell are privates for? Just use protected.” (Full disclosure: He was a really good programmer, better than me. I wrote some crazy code… So I have no right to say anything. Mind you I’ve learned my lessons. I’m constantly trying to improve!) Well, the argument is that both public and protected do not adhere well to encapsulation. I usually tries to use privates that I believe fit a certain situation. I usually leave member variables protected if I feel that child-classes may have some need for a variable. And the rest private if I feel that they should be private from child-classes. But the author’s argument for private members is sound. If child-classes need to have access to base-class member variables then perhaps one need to think hard about the design.
After all, one needs to design the classes by designing them as TYPES. This brings me back to my algorithm class oh so long ago… The abstract data-types. So one should design one’s classes as TYPES that are as good as the build-in types. A corollary of this is to have the so called “namespace organized functions” that operate on these types, to further encapsulation.
*Exception Safe design:
To me this is somehow linked to the concept of invariant based programming. And also the concept of programming by contract (e.g. pre/post-conditions.)
…
Now, I just need to put these concepts into practice. As the saying goes, *engage brain before pencil*. Haha.
