Creating High-Quality
Code
Hoa Nguyen
Outline
Chapter 5: Design in Construction
Chapter 6: Working Classes
Chapter 7: High-Quality Routines
Chapter 8: Defensive Programming
Chapter 9: The Pseudo code Programming Process
Chapter 5: Design in Construction
5.1 Design Challenges
5.2 Key Design Concepts
5.3 Design Building Blocks: Heuristic
5.4 Design Practices
5.5 Comments on Popular Methodologies
5.1 Design Challenges
What is “Software Design” mean?
The conception, invention, or contrivance of a scheme for
turning a specification for computer software into
operational software
The activity that links requirements to coding and debugging
5.1 Design Challenges
Design is a Wicked Problem
Design is a Sloppy Process
Design is about Tradeoffs and Priorities
Design involves Restrictions
Design is Nondeterministic
Design is Heuristic Process
Design is Emergent
5.2 Key Design Concepts
Good design depends on understanding a handful of key
concepts. This section discusses the role of complexity,
desirable characteristics of designs, and levels of design
5.2 Key Design Concepts
Managing Complexity
Accidental and Essential Difficulties
Importance of Managing Complexity
Divide system into sub-systems
Keep the routines short
Write code easy for understand
How to attach Complexity
Minimum the amount of essential complexity that anyone’s
brain has to deal with at any one time
Keep accidental complexity from needlessly proliferating
5.2 Key Design Concepts
Desirable Characteristics of Design
Minimal complexity (Primary goal)
Avoid make “clever” design
Ease of maintenance
Loose coupling
Extensibility
Reusability
High fan-in
5.2 Key Design Concepts
Desirable Characteristics of Design
Low-to-medium fan-out
Portability
Leanness
Stratification
Standard techniques
5.2 Key Design Concepts
Levels of design
Software system
Division into subsystems
or package
5.2 Key Design Concepts
Levels of design
Software system
Division into subsystems or package
Common Subsystems: Business rules, User interface, Database
access, System dependencies,
Division into classes
Division into routines
Internal routine design
5.3 Design Building Blocks: Heuristics
Find real world objects
Identify the objects and their attributes (methods and data)
Determine what can be done to each object
Determine what each object is allowed to do to other objects
Determine the parts of each object that will be visible to other
objects-which parts will be public and which will be private
Define each object’s public interface
5.3 Design Building Blocks: Heuristics
Find real world objects
Determine
Define thewhat
Identifyeachthe each
object’s
objects
parts object
can and
be
public
of done
each is allowed
interface
their to eachthat
object to do be
object
attributes to visible
(methods
will other
and objects
data)
to other
5.3 Design Building Blocks: Heuristics
Form Consistent Abstractions
5.3 Design Building Blocks: Heuristics
Encapsulate Implementation Detail
5.3 Design Building Blocks: Heuristics
Inherit – When Inheritance Simplifies Design
Hide Secrets (Information Hiding)
Secrets and the Right to Privacy
5.3 Design Building Blocks: Heuristics
Inherit – When Inheritance Simplifies Design
Hide Secrets (Information Hiding)
An Example of Information Hiding
Two categories of Secret
5.3 Design Building Blocks: Heuristics
Inherit – When Inheritance Simplifies Design
Hide Secrets (Information Hiding)
Barrier to information hiding
Excessive distribution of information
Circular dependencies
Class data mistaken for global data
Perceived preformation penalties
Value of information hiding
5.3 Design Building Blocks: Heuristics
Identify Areas Likely to Change
Identify items that seem likely to change
Separate items that are likely to change
Isolate items that seem likely to change
5.3 Design Building Blocks: Heuristics
Identify Areas Likely to Change
A few areas that are likely to change
Business rules
Hardware dependencies
Input and Output
Nonstandard language features
Difficult design and construction areas
Status variables
Data-size constraints
5.3 Design Building Blocks: Heuristics
Keep coupling loose
Coupling Criteria
Size
Visibility
Flexibility
Kinds of Coupling
Simple-data-parameter coupling
Simple-object coupling
Object-parameter coupling
Semantic coupling
5.3 Design Building Blocks: Heuristics
Look for Common Design Patterns
Patterns reduce complexity by providing ready-made
abstractions
Patterns reduce error by institutionalizing details of common
solutions
Patterns provide heuristic value by suggesting design
alternatives
Patterns streamline communication by moving the design
dialog to a higher level
5.3 Design Building Blocks: Heuristics
Look for Common Design Patterns
5.3 Design Building Blocks: Heuristics
Other Heuristics
Aim for strong Cohesion
Build Hierarchies
Formalize Class Contracts
Assign Responsibilities
Design for Test
Avoid Failure
5.3 Design Building Blocks: Heuristics
Other Heuristics
Choose Binding Time Consciously
Make Central Points of Control
Consider Using Brute Force
Draw a Diagram
Keep your Design Modular
5.4 Design Practices
Iterate
Divide and Conquer
Top-Down and Bottom-Up Design Approaches
Argument for Top Down
Argument for Bottom Up
Experimental Prototyping
Collaborative Design
How much Design is Enough?
5.4 Design Practices
Capturing your Design Work
Insert design document into the code itself
Capture design discussions and decisions on a Wiki
Write email summaries
Use a digital cameras
Save design flip charts
Use CRC (Class, Responsibility, Collaborator) cards,
Create UML diagrams at appropriate levels of detail
5.5 Comments on Popular Methodologies
Capturing your Design Work
Insert design document into the code itself
Capture design discussions and decisions on a Wiki
Write email summaries
Use a digital cameras
Save design flip charts
Use CRC (Class, Responsibility, Collaborator) cards,
Create UML diagrams at appropriate levels of detail
Chapter 5: Design in Construction
Key Points
Chapter 6: Working Classes
Class is a collection of data and routines that share a
cohesive, well-defined responsibility
A key to being an effective programmer is maximizing the
portion of a program that you can safely ignore while
working on any one section of code
Classes are the primary tool for accomplishing that
objective
Chapter 6: Working Classes
6.1 Class Foundation: Abstract Data Type (ADTs)
6.2 Good Class Interfaces
6.3 Design and Implementation Issues
6.4 Reasons to Create a Class
6.5 Language-Specific Issues
6.6 Beyond Classes: Packages
6.1 Abstract Data Type (ADTs)
A collection of data and operations that work on that data
An ADT might be a graphic window with all the operations
that affect it, a file and file operations, an insurance-rates
tables and the operations on it, …
6.1 Abstract Data Type (ADTs)
ADTs and Classes
ATDs form the foundation for the concept of classes
Class is ADT + Inheritance + Polymorphism
6.1 Abstract Data Type (ADTs)
Benefits
Hide implementation details
Changes do not affect the whole program
Make the interface more informative
Easier to improve performance
Program is more obviously correct
Program becomes more self-documenting
Do not have to pass data all over program
Able to work with real-world entities rather with low level
implementation structures
6.1 Abstract Data Type (ADTs)
Some examples
6.1 Abstract Data Type (ADTs)
Some examples
6.1 Abstract Data Type (ADTs)
Guidelines
Build or use typical low-level data types as ADTs, not at low-
level data types
Treat common objects such as files as ADTs
Treat even simple items as ADTs
Refer to an ADT independently of the medium it’s store on
6.1 Abstract Data Type (ADTs)
Handling Multiple Instances of Data with ADTs in Non-Object-
Oriented Environments
Option 1: Explicitly identify instances each time you use ADT
service
Option 2: Explicitly provide the data used by ADT services
Option 3: Use implicit instances
6.2 Good Class Interfaces
Good Abstraction - Define
Abstraction is the ability to view a complex operation in a simplified
form
6.2 Good Class Interfaces
Good Abstraction – How to get
Present a consistent level of abstraction in the class interface
6.2 Good Class Interfaces
Good Abstraction
Present a consistent level of abstraction in the class interface
Be sure you understand what abstraction the class in
implementing
Provide services in pairs with their opposites
Move unrelated information to another class
Make interfaces programmatic rather than semantic when possible
6.2 Good Class Interfaces
Good Abstraction
Beware of erosion of the interface’s abstraction under
modification
Do not add public members that are inconsistent with the
interface abstraction
Consider abstraction and cohesion together
6.2 Good Class Interfaces
Good Encapsulation
Minimize accessibility of classes and members
Do not expose member data in public
Avoid putting private implementation details into a class’s
interface
Do not make assumptions about class’s users
Avoid friend classes
Do not put a routine into the public interface just because it
uses only public routines
Favor read-time convenience to write-time convenience
Be very, very wary of semantic violations of encapsulation
6.3 Design and Implementation Issues
Containment (“has a” Relationships)
Implement “has a” through containment
Implement “has a” through private inheritance as last resort
Be critical of classes that contain more than about seven data
members
6.3 Design and Implementation Issues
Inheritance (“is a” Relationships)
Implement “is a” through public inheritance
Design and document for inheritance or prohibit it
Adhere to the Liskov Substitution Principle (LSP)
Be sure to inherit only what you want to inherit
6.3 Design and Implementation Issues
Inheritance (“is a” Relationships)
6.3 Design and Implementation Issues
Inheritance (“is a” Relationships)
Do not “override” a non-overridable member function
Move common interfaces, data, and behavior as high as
possible in the inheritance tree
Be suspicious of classes of which there is only one instance
Be suspicious of base classes of which there is only one derived
class
Be suspicious of classes that override a routine and do nothing
inside the derived routine
Avoid deep inheritance trees
6.3 Design and Implementation Issues
Inheritance (“is a” Relationships)
Prefer polymorphism to extensive type checking
Make all data private, not protected
6.3 Design and Implementation Issues
When use “Inheritance” and when use “Containment”
6.3 Design and Implementation Issues
Member Functions and Data
Keep the number of routines in a class as small as possible
Disallow implicitly generated member functions and operations
you do not want
Minimize the number of different routines call by a class
Minimize indirect routine calls to other classed
In general, minimize the extent to which a class collaborates
with other classes
6.3 Design and Implementation Issues
Constructors
Initialize all member data in all constructors if possible
Enforce the singleton property by using a private constructor
Prefer deep copies to shallow copies until proven otherwise
6.4 Reasons to Create a Class
Model real-world objects
Model abstract objects
Reduce complexity
Isolate complexity
Hide implementation details
Limit effect of changes
Hide global data
Streamline parameter passing
Make central points of control
6.4 Reasons to Create a Class
Facilitate reusable code
Plan for a family of programs
Package related operations
Accomplish a specific refactoring
Classes to avoid
Avoid creating god classes
Eliminate irrelevant classes
Avoid classes named after verbs
6.5 Language-Specific Issues
6.6 Beyond Classes: Package
Standards for creating own package
Chapter 6: Working Classes
Key Points
Chapter 7: High-Quality Routines
7.1 Valid Reasons to Create a Routine
7.2 Design at the Routine Level
7.3 Good Routine Names
7.4 How Long Can a Routine Be?
7.5 How to Use Routine Parameters
7.6 Special Considerations in the Use of Functions
7.7 Macro Routines and Inline Routines
7.1 Valid Reasons to Create a Routine
Reduce complexity
Introduce an intermediate, understandable abstraction
7.1 Valid Reasons to Create a Routine
Avoid duplicate code
Support sub-classing
Hide sequences
Hide pointer operations
Improve portability
Simplify complicated Boolean tests
Improve performance
7.1 Valid Reasons to Create a Routine
In addition, many of reason to create a class are also good
reasons to create a routine:
Isolate complexity
Hide implementation details
Limit effects of changes
Hide global data
Make central point of control
Facilitate reusable code
Accomplish a specific refactoring
7.2 Design at the Routine Level
Goal
Each routine do one thing well and not do anything else
How to make routines as cohesive as possible
Functional cohesion
A routine performs one and only one operation
Sequential cohesion
Communicational cohesion
Temporal cohesion
7.2 Design at the Routine Level
Unacceptable kinds of cohesion
Procedural cohesion
Logical cohesion
Coincidental cohesion
7.3 Good Routine Names
Describe everything the routine does
Avoid meaningless, vague, or wishy-washy verbs
Do not differentiate routine names solely by number
Make names of routines as long as necessary
To name a function, use a description of the return value
To name a procedure, use a strong verb followed by an
object
Use opposites precisely
Establish conventions for common operations
7.4 How long can a Routine Be?
Allow to grow up to 100-200 lines (without comments,
blank lines)
7.5 How to Use Routine Parameters
Put parameters in input-modify-output order
Consider creating your own in and out keywords
If several routines use similar parameters, put the similar
parameters in a consistent order
Use all the parameters
Put status or error variables last
Do not use routine parameters as working variables
7.5 How to Use Routine Parameters
Document interface assumptions about parameters
Limit the number of routine’s parameters to about seven
Consider an input, modify, output naming convention for
parameters
Pass the variables or objects that the routine needs to
maintain its interface abstraction
Use Named Parameters
Make sure actual parameters match formal parameters
7.6 Special Considerations in the Use of
Functions
Special Considerations in the Use of Functions
When to Use a Function and When to Use a Procedure
Setting the Function’s Return Value
Check all possible return paths
Do not return references or pointers to local data
7.7 Macro Routines and Inline Routines
How to use Macro Routines and Inline Routines in C++
Chapter 7: High-Quality Routines
Key Points
Chapter 8: Defensive Programing
8.1 Protecting Your Program from Invalid Inputs
8.2 Assertions
8.3 Error-Handling Techniques
8.4 Exceptions
8.5 Barricade Your Program to Contain the Damage Caused
by Errors
8.6 Debugging Aids
8.7 Determining How Much Defensive Programming to Leave
in Production Code
8.8 Being Defensive About Defensive Programing
8.1 Protecting Your Program from Invalid
Inputs
Check the values of all data from external sources
Check the values of all routine input parameters
Decide how to handle bad inputs
8.2 Assertions
Assertion is code that’s used during development – usually a
routine or macro – that allow a program to check itself as it
runs
When an assertion is true, that means everything is
operating as expected. When it’s false, that means it has
detected an unexpected error in the code
An Assertion usually takes 2 parameters: a Boolean
expression that describes the assumption that’s supposed to
be true, and a message to display if it is not.
8.2 Assertions
Guideline for using Assertion
Use error-handling code for conditions you expect to occur;
use assertions for conditions that should never occur
Avoid putting executable code into assertions
Use Assertions to document and verify pre-conditions and post-
conditions
For highly robust code, assert and then handle the error
anyway
8.3 Error Handling Techniques
Return a neutral value
Substitute the next piece of valid data
Return the same answer as the previous time
Substitute the closest legal value
Log a warning message to a file
Return an error code
Call an error-processing routine/object
Display an error message whenever the error is encountered
Handle the error in whatever way works best locally
Shutdown
8.4 Exceptions
Use exception to notify other parts of program about errors
that should not be ignored
Throw an exception only for conditions that are truly
exceptional
Do use an exception to pass the bulk
Avoid throwing exceptions in constructors and destructors
unless you catch them in the same place
Throw exceptions at the right level of abstraction
8.4 Exceptions
Include in the exception message all information that led to
the exception
Avoid empty catch blocks
Know the exceptions your library code throws
Consider building a centralized exception reporter
Standardize your project’s use of exceptions
Consider alternatives to exceptions
8.5 Barricade Your Program to Contain
the Damage Caused by Errors
8.5 Barricade Your Program to Contain
the Damage Caused by Errors
Convert input data to the proper type at input time
8.6 Debugging Aids
Do not automatically apply production constraints to the
development version
Introduce debugging aids early
Plan to remove Debugging Aids
8.7 Determine how much defensive
program to leave in production code
Leave in code that checks for important errors
Remove code that checks for trivial errors
Remove code that results in hard crashes
Leave in code that helps the program crash gracefully
Log errors for your technical support personnel
Make sure that the error messages you leave in are friendly
8.8 Being defensive about defensive
programing
Think about where you need to be defensive, and set your
defensive programing priorities accordingly
Chapter 8: Defensive Programing
Key points
Chapter 9: The Pseudo code Programing
Process
9.1 Summary of steps in Building Classes and Routines
9.2 Pseudo code for Pros
9.3 Constructing Routines for using PPP
9.4 Alternatives to the PPP
9.1 Summary of Steps in Building Classes
and Routines
Steps in Creating a Class
9.1 Summary of Steps in Building Classes
and Routines
Steps in Building a Routine
9.2 Pseudo code for Pros
Guideline for using Pseudo code effectively
9.2 Pseudo code for Pros
Guideline for using Pseudo code effectively
9.2 Pseudo code for Pros
Benefits
Make review design easier
Support idea of iterative refinement
Make change easier
Minimize commenting effort
Easier to maintain than other forms of design document
9.3 Constructing Routines by using the
PPP
Design the Routine
Check the prerequisites
Define the problem the routine will solve
Name of routine
Decide how to test the routine
Research functionality available in the standard libraries
9.3 Constructing Routines by using the
PPP
Design the Routine
Think about error handling
Think about efficiency
Research the algorithms and data types
Write the pseudo code
Think about the data
Check the pseudo code
Try a few ideas in pseudo code, and keep the best (iterate)
9.3 Constructing Routines by using the
PPP
Code the Routine
9.3 Constructing Routines by using the
PPP
Check the code
Mentally check the routine for errors
Compile the routine
Step through the code in the debugger
Test the code
Remove errors from the routine
9.3 Constructing Routines by using the
PPP
Clean up Leftovers
Check the routine’s interface
Check for general design quality
Check the routine’s variables
Check the routine’s statements and logic
Check the routine’s layout
Check the routine’s documentation
Remove redundant comments
9.4 Alternatives to PPP
Alternatives to PPP
Test-first development
Refactoring
Design by contract
Hacking?
Chapter 9: The Pseudo code Programing
Process
Key Points
