A Philosophy of Software Design
Content Introduction
This book addresses the topic of software design: how to decompose complex software systems into modules (such as classes and methods) that can be implemented relatively independently. The book first introduces the fundamental problem in software design, which is managing complexity. It then discusses philosophical issues about how to approach the software design process, and it presents a collection of design principles to apply during software design. The book also introduces a set of red flags that identify design problems. You can apply the ideas in this book to minimize the complexity of large software systems, so that you can write software more quickly.
Author Profile
John Ousterhout is the Bosack Lerner Professor of Computer Science at Stanford University. His current research focuses on new software stack layers to allow datacenter applications to take advantage of communication and storage technologies with microsecond-scale latencies. Ousterhout’s prior positions include 14 years in industry, where he founded two companies (Scriptics and Electric Cloud), preceded by 14 years as Professor of Computer Science at U.C. Berkeley. He is the creator of the Tcl scripting language and is also well known for his work in distributed operating systems and storage systems. Ousterhout received a BS degree in Physics from Yale University and a PhD in Computer Science from Carnegie Mellon University. He is a member of the National Academy of Engineering and has received numerous awards, including the ACM Software System Award, the ACM Grace Murray Hopper Award, the National Science Foundation Presidential Young Investigator Award, and the U.C. Berkeley Distinguished Teaching Award.
Contents
- Preface
- Chapter 1 Introduction
- Chapter 2 The Nature of Complexity
- Chapter 3 Working Code Isn’t Enough
- Chapter 4 Modules Should Be Deep
- Chapter 5 Information Hiding (and Leakage)
- Chapter 6 General-Purpose Modules are Deeper
- Chapter 7 Different Layer, Different Abstraction
- Chapter 8 Pull Complexity Downwards
- Chapter 9 Better Together Or Better Apart?
- Chapter 10 Define Errors Out Of Existence
- Chapter 11 Design it Twice
- Chapter 12 Why Write Comments? The Four Excuses
- Chapter 13 Comments Should Describe Things that Aren’t Obvious from the Code
- Chapter 14 Choosing Names
- Chapter 15 Write The Comments First
- Chapter 16 Modifying Existing Code
- Chapter 17 Consistency
- Chapter 18 Code Should be Obvious
- Chapter 19 Software Trends
- Chapter 20 Designing for Performance
- Chapter 21 Conclusion
- Summary