Creating High-Quality Code: Hoa Nguyen
Creating High-Quality Code: Hoa Nguyen
Code
Hoa Nguyen
Outline
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
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
Visibility
Flexibility
Kinds of Coupling
Simple-data-parameter coupling
Simple-object coupling
Object-parameter coupling
Semantic coupling
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
Key Points
Chapter 6: Working Classes
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)
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
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
Key Points
Chapter 7: High-Quality Routines
Reduce complexity
Introduce an intermediate, understandable abstraction
7.1 Valid Reasons to Create a Routine
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
Key Points
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
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