• 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

• Author: Dennis de Champeaux, Douglas Lea, and Penelope Faure
• Format: online HTML
• Price: free

This book is intended to help the reader better understand the role of analysis and design in the object-oriented software development process. Experiments to use structured analysis and design as precursors to an object-oriented implementation have failed. The descriptions produced by the structured methods partition reality along the wrong dimensions. Classes are not recognized and inheritance as an abstraction mechanism is not exploited.

However, we are fortunate that a multitude of object-oriented analysis and design methods have emerged and are still under development. Core OO notions have found their home place in the analysis phase. Abstraction and specialization via inheritance, originally advertised as key ingredients of OO programming, have been abstracted into key ingredients of OO analysis (OOA). Analysis-level property inheritance maps smoothly on the behavior inheritance of the programming realm.

While the book is mostly self-contained, people report that it does not serve as an introductory OO text. It helps to have had some previous exposure to basic OO concepts.

Chapters Include:

Part 1: Analysis

• Introduction to Analysis
• Object Statics
• Object Relationships
• Object Dynamics
• Object Interaction
• Class Relationships
• Instances
• Ensembles
• Constructing a System Model
• Other Requirements
• The Analysis Process
• Domain Analysis
• The Grady Experience

Part II: Design

• From Analysis to Design
• Description and Computation
• Attributes in Design
• Relationships in Design
• Designing Transitions
• Interaction Designs
• Dispatching
• Coordination
• Clustering Objects
• Designing Passive Objects
• Performance Optimization
• From Design to Implementation

http://g.oswego.edu/dl/oosd/