Software Design Guidelines

Keep public interface to a minimum.
Hide object implementation from public access.
Class users don't need to know anything about class implementation to use your objects effectively.
Changes in implementation should not require changes in user code.

To provide convenient ways of object initialization by users.
To initialize all data attributes to appropriate values.
To give object a good state right from the beginning of its lifetime.
To properly initialize base classes, in a hierarchical model of objects.
To allocate dynamic memory and resources, if needed by object implementation.
C++ programmers should also worry about object destructors and memory/resource deallocation.

When design of an object is complete, an object becomes an artifact of the system.
That is,
- a unit of maintenance
- often a unit of documentation
- a unit of testing.
Could such unit be reused in the future designs?
- Claim that purpose of OO technology is reuse of objects is largely overstated.
- Concepts such as polymorphic operations and encapsulation of internal data are actually much more important benefits.
- Software architecture has to support not only reuse, but also behavior, functionality, performance, economic and technological constraints, trade-offs, and many other things.
  - However, if there is a potential for reuse in the future, it should definitely be considered part of the design consideration.

Naming consistency of classes, attributes, operations, and constants involves:
- style and structure of names
- UPPER_CASE vs. lower_case vs. MixedCase vs. Title_case vs. camelCase
- consistent use of abbreviations (or ban them entirely.)
- Using code alignment and whitespace.
See also: Camel Case Notation

Data abstraction and hiding closely relates to the scopes of variables and operations.
In view of good design we must pursue the goal of localizing attributes and behaviors as much as possible.
This greatly improves debugging, testing, documentation, and extensibility of the entire system.
Keeping minimal scopes emphasizes good programming style.

Consider:


    int temp;
    void swap( int* pleft, int* pright )
    {
        temp = *pleft;
        *pleft = *pright;
        *pright = temp;
    }

Better:


    void swap( int* pleft, int* pright )
    {
        int temp = *pleft;
        *pleft = *pright;
        *pright = temp;
    }

Design with future maintenance in mind.
Add comments when necessary.
Every non-trivial piece of code deserves a comment.
Document your code.
Use consistent code style.
Minimize dependencies, that is, reduce the number of static variables to a minimum.
Reduce clutter of unnecessary temporary variables.

Software development is an iterative and incremental process
Each stage of the process is revisited repeatedly during the development, and each visit could refine the end product.
Pretending that you are starting from a clean slate can cause serious problems.
Pretending that the world ends at the "final delivery" can cause equally serious problems for your successors (often yourself in a different role a year from now.)
That is, "design" is almost always a redesign based on a previous design and some implementation.

The development process has three stages:
- Analysis: defining the scope of the problem to be solved
- Design: creating an overall structure for a system
- Implementation: writing and testing the code.
An iterative nature of this process is significant and suggests that these stages are not numbered.
Staff at all levels should be encouraged to talk regularly with individuals involved in "the other" stages of the development.
However, it is important to apply an appropriate degree of formality for a given project and to maintain an appropriate degree of separation between these phases.