I wanted to accept an answer on this question, but I couldn't decide on one answer to bestow the check mark on. As such I've upvoted the original authors and created this as a summary answer. Thanks to everyone who took a few minutes, I found that the insight you provided gave me a good direction and a little reassurance that I wasn't off the rails.
Well the first is the pitfall of exposing too much information. The default should be private, not public.
After that comes too many getters/setters.
I felt that I had observed this problem in action in the past. Your comments made me also remember that by hiding the underlying variables and their implementation, I am free to change their implementation without destroying anything dependant on them.
Design the interface before you even start thinking about the implementation.
Interface design and implementation often go hand in hand in consecutive iterations until the final interface is crystallized.
I thought Dominic's comment was a great ideal to aspire to, but I think that Gene's comment really hits the reality of the situation. So far I've seen this in action ... and feel a little better that it's not uncommon. I think that as I mature as a programmer I'll lean towards more complete designs, but right now I still suffer from jump in and get some code written-itis.
I started slow, with small/medium-size procedural apps, and no mission-critical stuff at work.
in the original procedural code, separate the data structures from the obsever/modifier code
This makes a lot of sense ... I liked the idea of keeping things working at work, but to refactor some of the non-critical stuff with classes.
One thing you definitely don't want to do is have a field that must be checked for consistency in the mutator, and leave it public
I've known for a while that this is one of the strengths of encapsulating the data... being able to enforce consistency and for that matter conditions/ranges/etc.
Someone thinking that they should stick to the OO paradigm and treat the others on the order of the goto statement in levels of immorality are really missing out by not looking at this paradigm.
The metaprogramming capacity of templates is also quite impressive.
I originally missed a lot in Crazy Eddie's answer, I think because I hadn't read up on some of the topics mentioned... like metaprogramming. I think the great message in CE's post was that C++ is such a blend of capabilities and styles that each should be used to their best potential... including imperative if that's what makes sense.
So again, thanks to everyone who responded!