Book Review: Implementation Patterns

Posted by Amr Elssamadisy on Nov 06, 2007

Community

Java,

Agile

Topics

Programming ,

Object Oriented Design

Tags

Patterns and Practices ,

Best Practices ,

Patterns

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.  

RelatedVendorContent

Right Collaboration Architecture Drives Business Transformation

Advanced Java Memory Analysis

Innovation in Your Data Centre

Agile Development: A Manager's Roadmap for Success

The Agile Project Manager

Related Sponsor

VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.

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:

1. Communication
2. Simplicity
3. Flexibility

The principles are:

1. Local consequences
2. Minimize repetition
3. Logic and Data together
4. Symmetry
5. Declarative Expression
6. 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:

1. Class: patterns about how to create classes and interfaces.
2. State: patterns concerned with data.
3. Behavior: patterns concerned with functionality but not necessarily where they reside in classes.
4. Methods: patterns concerned with the different types of methods in classes.
5. Collections: patterns concerned with aggregate data.
6. 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.

1. Back to top

   Waiting for it for a long time

   Nov 6, 2007 4:19 PM by Michael Hunger

   The values and principles discussion sound like the one from XP2. How does it differ from it and does it? What about the accountability Kent emphasises on so much and what about testing. Kent being one of the two JUnit guys and now an Agitar fellow the Implementation patterns should deal with testability as well?
   I also hope to reflect the stuff I'm doing. And become better at teaching these values, principles and patterns to my fellow developers.
   I'd really liked to have the Implementation Patterns as a Pattern Language as described by Kevlin, Frank and Doug in POSA5. There you have everything: vision, values, context, practices and pattern influencing context and each other in their application. I already wrote Kent on this. Unfortunately he thinks that covering XP and Implementation Patterns inside a pattern language distracts the reader to much from its core essence.
   Imho it would gain a lot from reevaluation as a pattern language.
   Another question ist the applicability of patterns. To decide when and how to apply a pattern and when to choos not to apply it. This ist the most difficult part for most developers.
   So I'm looking forward for my preorder to get here.
   Did you review the manuscript or the printed book?
   
   Michael

   Reply

2. Back to top

   Re: Waiting for it for a long time

   Nov 6, 2007 4:37 PM by Amr Elssamadisy

   
   The values and principles discussion sound like the one from XP2. How does it differ from it and does it?
   

   
   It is the same approach - values and principles - as in XP Explained, v2. The values are a subset of the XP values, which I assume is because programming is only a subset of the XP practices. As for principles, they diverge even more.
   
   As for pattern languages... This book reads very well. Kent's style is - IMHO - much clearer. Part of it is personal preference, the other part is the book itself is simple.
   
   Finally, I reviewed an early edition from the publisher and just got my official print yesterday.

   Reply

• Older >