(ref.doc)C++ Programming Language

Bjarne Stroustrup (Note:
 Stroustrup)

The C++ Programming Language (second edition)
Addison-Wesley
ISBN 0-201-53992-6

2.3.9 Type equivalence
[typedef is a] mechanism for declaring a new name for a type without
introducing a new type. [...] This can be a convenient shorthand.

r.10.1.1
  "When virtual base classes are used, more than one
   function, object, or enumerator may be reached through
   paths through the [DAG] of base classes.  This is an
   ambiguity unless one of the names found *dominates*
   the others.  The identical use with nonvirtual base
   classes *is an ambiguity*; in that case more than one
   subobject is involved.

  "A name 'B::f' dominates a name 'A::f' if its class
   has 'B' has 'A' as a base..."

11 Design and Development
11.1 Introduction
A few major themes run through this chapter:
- The most important single aspect of software development is to be
  clear about what you are trying to build.
- Successful software development is a long term activity.
- The systems we construct tend to be at the limit of the complexity
  that we and our tools can handle.
- There are no "cookbook" methods that replace intelligence,
  experience, and good taste in design and programming.
- Experimentation is essential for all non-trivial software
  development.
- Design and programming are iterative activities.
- The different phases of a software project, such as the design,
  programming, and testing, cannot be strictly separated.
- Programming and design cannot be considered without also considering
  the management of these activities.

Design and programming are human activities: forget that and all is
lost.

11.3.3 Design Steps
However, here is a series of steps that has worked for some people:
1. Find the concepts/classes and their most fundamental relationships.
2. Refine the classes by specifying the sets of operations on them.
 a. Classify these operations. In particular, consider the needs for
    construction, copying, and destruction.
 b. Consider minimalism, completeness, and convenience.
3. Refine the classes by specifying their dependencies on other
   classes:
 a. Inheritance.
 b. Use dependencies.
4. Specify the interfaces for the classes.
 a. Separate functions into public and protected operations.
 b. Specify the exact type of the operations on the classes.


13.3 Abstract types
Keywords: mixin, protocol class, abstract interface, abstract type
p 436: Typically, an abstract type has its operations specified as
pure virtual functions and has no data members (except an implicit
pointer to a table of virtual functions. The reason is simply that, in
most cases, adding a non-virtual function or a data member would
require assumptions that would constrain the possible implementations.
The notion of an abstract type as presented here is closely akin to
the traditional notion of providing a clean separation between an
interface and its implementations.