[Effective-cpp] More Effective C++ Item 32 - Program In The Future Tense

[Tarjei Knapstad]

On Thu, 2003-05-29 at 20:19, Neil Youngman wrote:

<snip>

> A technique that may help is to enforce design constraints in the
> code, as well as just documenting them, e.g if you intend that a class
> should never be derived from, then use C++ to prevent derivation, as
> shown in item 26. Conversely, if derivation is permitted, then declare
> a virtual destructor, regardless of whether that is an immediate
> requirement. Don't rely on default copy constructors and assignment
> operators. Define then yourself or declare them private.
> 

Is it not an accepted practice to allow the defaults here as long as you
don't have pointer attributes (and you're certain that your other
attributes are copyable)? I'm in the habit of doing the above mentioned
thing with either hiding them or explicitly implementing them, but
sometimes I must admit I wonder why I bother... then I grab some coffee
and forget all about it - at least it's not wrong.

<snip>

> 
> Provide complete classes, even if some parts may not be used
> immediately. This reduces the need to go back and modify them later.
> 

I have to disagree with this as it also reduces your chances to meet
your next deadline. When I design a class I make sure it provides
whatever methods/attributes it's clients will need - and nothing more. I
usually have ideas for lots of "cool" functionality that may belong very
naturally to whatever concept the class models, but if it's not needed
by the clients it just won't go in. I may even document the
possibilities for future extensions, but never implement them. The only
area I'm prepared to allow this is for classes that do arithmetics -
they should supply a complete set of the operators they're meant to
support.

IMHO, "Provide complete classes, even if some parts may not be used
immediately", smells a lot like spending too few hours in the design
department to me....

<and snip again>

Cheers,
--
Tarjei