A Philosophy of Software Design, 2nd Edition
  • 简体中文
  • English
  • 繁体中文
GitHub
  • 简体中文
  • English
  • 繁体中文
GitHub
  • Introduction
  • Preface
  • Chapter 1 Introduction
  • Chapter 2 The Nature of Complexity
  • Chapter 3 Working Code Isn’t Enough(Strategic vs. Tactical Programming)
  • 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 Decide What Matters
  • Chapter 22 Conclusion
  • Summary

Chapter 19 Software Trends

As a way of illustrating the principles discussed in this book, this chapter considers several trends and patterns that have become popular in software development over the last few decades. For each trend, I will describe how that trend relates to the principles in this book and use the principles to evaluate whether that trend provides leverage against software complexity.

19.1 Object-oriented programming and inheritance

19.2 Agile development

19.3 Unit tests

19.4 Test-driven development

19.5 Design patterns

19.6 Getters and setters

19.7 Conclusion

Whenever you encounter a proposal for a new software development paradigm, challenge it from the standpoint of complexity: does the proposal really help to minimize complexity in large software systems? Many proposals sound good on the surface, but if you look more deeply you will see that some of them make complexity worse, not better.

Last Updated: 5/14/25, 1:24 AM
Prev
Chapter 18 Code Should be Obvious
Next
Chapter 20 Designing for Performance