Kent Beck's new book, Implementation Patterns, is a book about writing code in Java. The patterns in this book are based on Kent's reading of existing code as well as his own programming habits. These patterns are about developers communicating through code which is reminiscent of his earlier work on Smalltalk Patterns. They are lower level than design patterns and about the same granularity as Larman's GRASP patterns. The patterns in this book are meant to be a coherent view of how to write code people can understand that serves human as well as economic needs.
A Theory of Programming
Of course, the notion of what is good code - let alone great code - is one that not all developers will agree upon. Kent presents his Theory of Programming as foundation for discriminating code quality. In Chapter 3, after a couple of introductory chapters, one on the goal of the book and the other on patterns, Kent describes two cross-cutting concerns in programming: values and principles.
The values are the universal overarching themes of programming. When I am working well, I hold dear the importance of communicating with other people, removing excess complexity from my code, and keeping my options open. These values - communication, simplicity, and flexibility - color every decision I make while programming.
The principles described here aren't as far-reaching or pervasive as the values, but each one is expressed by many of the patterns. The principles bridge between the values, which are universal but often difficult to apply directly, and the patterns, which are clear to apply but specific. ... Faced with ambiguity, understanding the principles allows me to "make something up" that is consistent with the rest of my practice and likely to turn out well.
Kent then discusses the values and principles in detail. The patterns in the book all refer back to the values and principles - they help the developer understand how each pattern helps achieve the larger objectives.
The values are:
- Communication
- Simplicity
- Flexibility
The principles are:
- Local consequences
- Minimize repetition
- Logic and Data together
- Symmetry
- Declarative Expression
- Rate of Change
This chapter is followed by a chapter on the motivation - mainly economic motivation - that drives software development. Simply put, we put most of our time in maintenance of software. The cost of change, in turn, is the sum of understanding the code, changing the code, testing the code, and finally deploying the code.
The Patterns
The patterns are written in essay format and cover everything from when you should create a data field in a class, to equality methods, to subclassing. The patterns are grouped into chapters by:
- Class: patterns about how to create classes and interfaces.
- State: patterns concerned with data.
- Behavior: patterns concerned with functionality but not necessarily where they reside in classes.
- Methods: patterns concerned with the different types of methods in classes.
- Collections: patterns concerned with aggregate data.
- Frameworks: patterns concerned with addressing aspects of building a framework.
Some examples of the patterns covered are as follows: (Kent presents them much more elegantly than the summaries here.)
- From the Class patterns:
- Simple superclass name: the tension between being concise and expressive is discussed. Kent discusses how to come up with a good name for a superclass.
- Qualified subclass name: Name subclasses to communicate the similarities and differences with a superclass. Because a superclass is not referenced as frequently as a sublcass the names do not have to be as concise.
- From the state patterns:
- Direct access: such as x=10 is very clear and concise. Too much of this also clutters the code.
- Lazy initialization: it sometimes makes sense to defer initialization if the cost of initialization is significant.
- From the method patterns:
- Composed method: methods call out to other methods, each of which are roughly the same level of abstraction.
- Equality method: define the equals() and hashCode() methods together for correct equality.
Conclusion
Kent provides us with his experience in an elegant and concise format (the entire book, with appendices, is 156 pages). He does not give rules, but gives values, principles, and rules of thumb:
There is no universal rule. Programmers need to think, communicate, and learn. That's part of being professional.
This is a book that is useful for both junior as well as senior developers - each will come away with something different. Those new to software development will see development through the eyes of one of the most talented developers today. Others with more experience will be able to reflect on why they do things the way they do - practices take on a different meaning by focusing on why they are done. Finally, tying the values and principles (but especially the values) to software development makes everything different - in a very good way.