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

Go down

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

Post by Donutz on Sun Dec 11, 2011 2:59 pm

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
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
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
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

[You must be registered and logged in to see this link.]

PLEASE I NEED YOUR SUPPORT......The more registers/logins/clicks to your URL_TRACKERS the more points you get on a daily basis. ----kindly click my url please please please
----> [You must be registered and logged in to see this link.]
This event will end on December 31st 2011 and we will pick the first 5 with highest points.
According to points earned – the highest will get the biggest gift and so on. Each gift is worth $50 to $500 or even more.
Donutz-Zone Admin
Donutz-Zone Admin

Posts : 555
Points : 1456
Repute : 0
Join date : 2011-10-29
Age : 28
Location : C:/Program files/Donutz/Zone


Back to top Go down

Back to top

- Similar topics

Permissions in this forum:
You cannot reply to topics in this forum