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

[Neil Youngman]

On Wednesday 04 June 2003 11:58 am, you wrote:
> 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.

There's no doubt that the default constructors are adequate in many 
instances. Implementing your own could aid long term maintainability, in that 
it avoids somebody adding a pointer and updating the existing functions, but 
not realising that an assignment operator and a copy constructor need to be 
added.

Personally I do sometimes leave these to the default, but it should be a 
conscious decision, with implementation of these operators being the default, 
rather than the exception. Ideally it should be commented in the code to show 
that you haven't just forgotten about it. 

> <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>

I don't think he means all the bells and whistles. It's more about things 
like providing all the relational operators or none. This seems like a 
reasonable goal, but it comes down to your interpretation of complete. 

This sounds like EC++ item 18 (Strive for class interfaces that are complete 
and minimal). "A complete interface is one that allows clients to do anything 
they may reasonably want to do. ... although it may not be as convenient as 
clients might like."

Ultimately completeness is a design objective, which has to be traded off 
against other objectives, like actually delivering something.

HTH

Neil