[Exceptional C++ Style] Item 18 - Virtuality

[Timothy Wright]

> 
> > Then I get a new requirement that
> > blows away what I have done.
> 
> Precisely because of changing requirements and evolving systems, it's important
> to "travel light". The "old school" was to try to anticipate every concievable
> way the system might need to evolve, and build in flexibility for that from the
> beginning. However, if you're wrong, you've just done unnnecessary work, and
> having had to maintain it, for no reason. Moreover, even if you're right, you
> may have had to work with increased complexity for a long time before you may
> need it.
> 
> Thus, unless you're pretty sure you need something, and/or it's hard to refactor
> the design to it later, it may pay to postpone it. The "new school" is to keep
> the system in shape (refactored), so that you may change it any way you need,
> when you need to. Adaptability, rather than trying to predict.

Yes, I am beginning to understand that.  My designs that tend to be
large and couple many classes give me the biggest problems in the long
run, they smell.  So I am always looking for best practices like NVI
to use, bits of knowledge so I don't have to learn by painful
experience.  But, as people pointed out, NVI has problems too. 
Ultimately, I find out what smells and what does not by experience and
I have not found (maybe it can't exist) a good design book that gives
me more ideas on what is good and what is bad.  Design Pattern and
refactoring books seem to come closest. The problem with the advice
"keep it simple but not too simple" is that it does not answer
specific questions.  Is NVI good?  Should I use the pimpl design
(another Herb's suggestions) everywhere?  What is simple and what adds
too much complication?  Keeping member variables private is considered
a good idea but does add complexity but everyone feels that it is a
good price to pay.

I guess that is why ACCU and these discussion groups exist. :-)

Regards

Tim