Taligent’s Guide to Designing Programs: Well-Mannered Object-Oriented Design in C++

• Author: Taligent Inc.
• Format: online HTML
• Price: free

A quick overview of Object-oriented program design, with special regard for operating-system development, this book will be of the greatest interest to those developers who are working with Taligent and its operating partners, as well as many other C++ programmers who are interested in a provocative summary of good OOP techniques.

Chapters include:

• Architectural goals
• Object-oriented architecture
• All interfaces are expressed through objects
• Commonality is managed through inheritance
• Objects are leveraged wherever possible
• Frameworks provide the foundation
• Let resources find you
• Putting it all together
• Reflect the client’s view
• Let resources find you
• Express all interfaces through objects
• Preserve class invariants
• Object-oriented design with C++
• C++ doesn’t express full object interface
• C++ requires definition of special member functions
• Use type inheritance to share protocol
• Useimplementation inheritance to override behavior
• Design the interfaces between the base and derived classes
• Guarantee use of derived classes as arguments
• Implement full protocol in derived classes
• Preserve semantics in a derived class
• Avoid deep nesting in lightweight objects
• Be aware of problems with virtual bases
• Avoid multiple occurrences of a base
• Design performance in
• Conduct performance analysis
• Perform controlled experiments
• Use static objects instead of temporaries
• Use chunky iteration for performance
• Use cache objects
• Object bloat
• Lost object focus
• Hardening of the architecture
• Structification
• Modulitis
• Managers are not objects
• Collections of functions are not objects
• Encapsulation leakage
• Empty base classes
• Overeducated base classes
• Overachieving base classes
• Distinguish is-a from has-a relationships
• Include copyright notices
• Use comments
• Include function prototypes
• Do not use code names in filenames
• Enclose definitions in header files
• Include only related classes in one file
• Use specific names
• But use generic names for abstract base classes
• Avoid abbreviations
• Use special names for copy, create, and adopt routines
• Use global names only for classes
• Follow member function conventions
• State explicit use of public, private, and protected
• Use separate class definition sections
• Avoid raw C types with dimensions
• Use dimensionless raw C types
• Avoid type casting
• Silent coercion
• Cast operators
• Use consistent return types for assignment operators
• State typedef class names before specifications
• Pass variables when possible
• Use array arguments instead of pointers
• Limit default arguments
• Avoid functions with unspecified arguments (…)
• Avoid returning pointers without allocation
• Use pointers to make multiple references
• Use references for a one-time reference
• Allocate storage only if you must
• Pretend everything is a primitive
• Use const instead of #define constants
• Use enum instead of sets of constants
• Use inlines instead of function macros
• Use templates for specialized functions and classes
• Don’t use goto
• Avoid magic numbers
• Avoid bit flags (& and |)
• Avoid using arrays as local variables or object fields
• Avoid homegrown utility classes
• Use the Name Server
• Hide allocation inside a class
• Don’t assume use of a heap
• Clarify ownership of storage in interfaces
• Don’t use very large local variables or members
• Avoid static objects
• Modifiable statics in a library
• Consider alternatives to temporary objects
• Binary compatibility considerations
• Adding virtual and nonvirtual functions
• Changing a function from inline to noninline
• Removing private nonvirtual functions not called by inlines
• Using classes internal to your implementation
• Use virtual functions if overrides are possible
• Rearranging, adding, and removing private data members with restrictions
• Inlines that call something else
• Inline function definitions in .C files
• Inlines for extreme efficiency
• Don’t write inlines in declarations
• Inlines for exporting private and protected members
• Empty special members
• Virtual inline functions where the type is not known
• Define class abstractions
• Decide now what might be overridden later
• When to use pure virtual functions
• Private virtual functions to control access
• Base class constructors cannot call virtual functions
• Destructors are not automatically virtual
• Switch statements indicate polymorphism
• When to use virtual assignment
• Exceptions checklist
• Exceptions syntax
• Avoid interface specification
• Perform resource recovery
• Automatic objects
• Passing exceptions
• TJanitor
• What to subclass
• When to subclass
• When to signal an exception
• When to recover an exception
• Strive for uniform distribution
• Do not implement Hash via member functions
• When equality does not apply
• Equality between different types
• Taxonomy of surrogates
• Explicit masters
• Handle surrogates
• Hidden masters
• Surrogates that view masters
• Follow naming conventions
• Use copy semantics wherever possible
• Avoid storage manipulation in open code
• Allocate subobjects on the heap for debugging
• Synchronization techniques
• Synchronization and problems with memory access
• Synchronization of global and static variables
• Shared memory between tasks
• Shared heaps
• Shared memory problems with const
• Static destructors for subsystem cleanup
• Create objects in a valid state
• Use flattening rather than dynamic class instantiation
• Check for self-assignment with operator=:
• Balance overloaded operators
• Use static members as constructors
• Differentiate overloaded constructors
• Hide implementation classes
• Use nil pointer deletion
• Issues in overloading and overriding classes
• Control class access
• Language and hardware assumptions
• Safe assumptions
• Bad assumptions
• Synchronization
• Portable data
• Assembly language
• Nonportable code
• Template conventions
• Include file conventions
• General rules for implementation classes
• The example class: an owning stack
• Sharing the implementation through private inheritance
• Class definitions
• Naming conventions
• Instance variables
• Type-specific methods and implementation class constructors and destructors
• Inlining the class template’s public methods
• Class templates that inherit from specialized classes
• An implementation sharing example
• Sharing the implementation by delegating to a member
• An example of delegating to a member
• The delegation example’s naming conventions
• The delegating-to-a-member example

http://root.cern.ch/TaligentDocs/TaligentOnline/DocumentRoot/1.0/Docs/books/WM/WM_1.html