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

Sponsor Advertisement

My image
  • 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

Leave a Reply

Your email address will not be published. Required fields are marked *