on February 18, 2008
The right title should be something like... "Kent Beck on writing readable code". The word "pattern" is way out of context, and will induce you to expect to find something way more precise, detailed and technical than then general advice that this book has to offer. This text could be considered like a chance to have a chat with Kent Beck discussing his ideas on the importance of writing readable code, and on general guidelines for code clarity and expressiveness. I have seen a review complaining about using Java for the examples, but the truth is, you will see very little code in this book. I am also not very sure of the idea target reader for this work. An experienced programmer has already figured out this general advice by himself, but the level of abstraction and detail is too terse to be useful to a beginner. I believe that more material, more detail and a more tutorial-like style could have made this book a worthwhile read for a junior developer. As it is , I have to say it, but I have to rate it as a pretty useless book. I am a big fan of Kent Beck, I admire his programming style, his 'very good habits' and all his did with the XP movement. Together with Martin Fowler, and Allen Holub he's one of those guys who can really have a deep influence on the way you program and think about Object Oriented programming, but this time he' really been a bit self condescending. And the price.. come on..40 bucks for this? You should be ashamed...
First off, this is a very thin tome. Which would make you expect a brisk pace, but instead, it's strangely just laconic. A lot of it is so elementary, it is kind of maddening. At one point, Kent tells us that if we need to fetch the time for a number of local variables, we ought use a local variable to 'freeze time.' The biggest problem here, however, is that when the book does turn to a topic that is worthy of some attention, the same paucity produces a feeling of futility: some of idioms, like collecting parameter, for instance, come up. No discussion of how it is a gateway to Visitor, nothing really interesting in fact, just a short little paragraph. Another section on parallel hierarchies ends with the author saying that he figured out how to solve his rather stilted example by introducing a CashFlow object. But he goes on without explaining it. Now, consider the fact that I believe books should ONLY take up topics like that one. This book is greatly confused about who it is for. The reality is this is probably best suited as a tome for people who have been doing basic programming but have not become really mature programmers. The problem is that it only does this in a way that I don't think will help those who have not crossed the bridge to do so. Ironically, I think the main use for this book will be to make people who are doing a lot of these things feel better about it.
on January 10, 2008
Pros: Gave me a tiny bit more insight into how a programmer I admire (Beck) thinks. Also the hand-drawn diagrams were intuitivie and easy to grasp.
Cons: Not much material. Book could have been half of its already short length. You sort of got the sense Beck was running out of things to say - the chapter on Collections has graphs of the running times of various collections, and an Appendix is devoted to the code used to create the graphs.
on March 28, 2008
Well written and organized, with a lot of short code fragments to illustrate the main points. However I have agree with the reviewer who suggested that this book should have been titled "Kent Beck on writing readable code". I'd add to this that the book is quite Java specific. Fine with me, but this needs to be pointed out. The book would have been more interesting to me if it documented the different approaches in use (along with their advantages and drawbacks) e.g. for choosing between checked and unchecked exceptions. Instead we get a few general statements about what exceptions are, and some suggestions along the lines of "low-level exceptions should be wrapped with high-level exceptions". The level of detail is often not enough to be interesting for somewhat experienced developers, but the book may be too abstract for beginners. Given the compact size of the book you'll still get good value for your time from reading it. Just don't set your expectations too high -- or expect to get good value for your money...
on August 2, 2008
The book is about writing readeable/maintanable code. It's an interesting/important subject.
The first few (1-3) pharagraph is good , they clearly explain the values/principles of the topic.
Then the book tries to apply these pricnciples in a structured way - classes, state, behaviour, methods. This is ok, but there's too much repetition going on. And the examples are very small/specific, some more complex/longer examples would be much better.
Then there's 2 whole paragraph about the performance characteristics of various collections (map,hash,etc.), and the description of the framework used to benchmark them. I don't think it has to do anyhting with the topic of the book, and it was probably included to increase the number of pages (by 30 to 150).
Finally, there's also a chapter "Evlolving Frameworks" which is mostly about JUnit 3->4 improvements done by the author. It's an interesting chapter focusing mainly on compatibility issues related to framworks.
So i think this topic from this author would deserve a much better book.
on January 29, 2011
I've read a number of books by Mr. Beck; his Extreme Programming and Agile Programming books offer keen bits of insight and advice and are well written.
This book is ... not. Or rather, while the prose itself is readable, there is very little of any kind of substance here. The subject matter that is addressed is on the level of "See Spot. Spot is a Dog. Dogs like to run. Run, Spot, Run.", in terms of Object-Oriented Programming. And with about as much insight offered.
I was expecting a book of (hopefully) language-neutral programming idioms; what the book is is a simpleton's introduction to the parts of a Java program - "This is a object. An object has fields, which store data, and methods (or functions) which work on data.", etc.
Moreover, I cannot determine who the audience is intended to be. Beginning programming students have their teachers, textbooks, and fellow students, all of whom can do a better job of explaining the actual subject matter than this book. Existing professionals - or even college students - who are pursuing programming will already have long since absorbed this knowledge. After thought, I can only conclude that the only possible audience is Mr. Beck's wallet.
on January 18, 2009
The book contains a number of low-level programming techniques for improving design of a program. Kent Beck is grand master of programming and a great communicator. If there is one thing you can learn from this book is to communicate design effectively with the code. The book is fairly concise and consists of ten chapters and 130 pages.
Due to his pioneering work in design patterns, Kent uses patterns to identify common programming techniques and similar to his extreme programming style for agile development he divides those techniques into values, principles and patterns. The values focus on high level goals such as communication, simplicity, flexibility. The principles focus on local consequences (minimize side-effect), DRY, keeping data/logic together, symmetry, decalartive (annotations), rate of change (Reuse/Release Equivalency Principle).
The chapter 5 describes different ways of organizing the code using classes, interfaces, versioned interface, abstract class, value object, etc. Kent shows importance of dependency inversion principle of coding to interfaces. He provides trade-offs between interfaces and abstract class such as change in implementation and change of the interface itself. One of the hardest thing in real world is progression of interfaces with new behavior and Kent describes versioned interface for it. Kent also encourages use of value or immutable objects to make the program side-effect free as in functional languages. He bemoans procedural interfaces due to temporal depdency they impose. Inheritance is also most difficult to get right, so Kent gives a lot of advice on that to make sure subclasses follow Liskov Substition Principle. Kent describes discourages use of conditional logic and encourags delegation technique based on polymorphism. He also shows pluggable selector briefly to implement plugin like behavior. Finally, he discourages of use of library classes with static methods and encourages use of instance methods.
The chapter 6 describes patterns for state such as access, variables, parameters, initializations, etc. Unlike functional languages that don't allow mutable state, imperative languages have to manage state that changes over time. Kent prefers indirect access to the state rather than direct especially when there is dependency between multiple pieces of data. Kent prefers keeping scope of variables local. This chapter also gives good advice on naming variables and parameters. Finally, this chapter describes techniques for eager and lazy initialization.
The chapter 7 describes patterns for control flow, methods and exceptions. In object oriented languages messages are fundamental mechanism for controlling workflow and communicating with the objects. Kent also describes technique for double dispatch (similar to visitor pattern) that provides polymorphic behavior but at the cost of additional coding and maintenance overhead. Other topics include providing guards, naming method and exception handling.
The chapter 8 describes how to divide logic into methods. The chapter describes composed method for calling other methods. It encourages use of symmetry and having same level of abstraction for called methods. Kent also shows use of Method object or Function object that mimics functional style of programming. This chapter also describes conversion methods, factory methods, getter/setter methods and advice of returning copy from the methods instead of internal references.
The chapter 9 describes collections such as arrays, lists, sets, map.
The final chapter describes how to evolve frameworks without breaking the applications. Kent borrows a lot of his experience from JUnit framework and Eclipse (his buddy Eric Gamma). One of interestic topic is how to use objects and the chapter provides three styles including instantiation, configuration and implmentation. Kent shows how implementation technique allow clients to implement a framework interface and extend behavior. Kent also describes trade-offs of extending interfaces and using specialized interfaces as used by AWT (LayoutManager2). The chapter also offers advice on use of internal classes by clients and how they can be instantiated using constructors, factories, etc.
This book shows a lot of techniques and patterns that most experienced programmers knowingly or unknowningly use on daily basis. Nevertheless, it helps to review these techniques and some trade-offs for them. Though, I wish the book gave a lot more examples and described antipatterns as I often found most of the topics a bit dull.
on January 24, 2015
This book is in dire need of a second edition and the first edition taken off the shelves. The book is tricky to read even for a person who has read design patterns books prior to this. It is very vaguely written. The only thing that is clearly stated is the topic headlines. As far as explaining the concepts in code is minimal. It explains important topics in a single paragraph and off you go. I had to read the paragraphs and try to link the concepts to patterns and techniques I already know. Words like: Defensive coding, adapter pattern etc...are left out, instead explained in a vague and short paragraph. A book like this should be oriented in a way that makes the reader pick up a computer and code to test for him/herself. But it would be very tricky for a person with little to medium experience to pick up a computer and code. Which is a shame because we need people to start coding instead of talking about coding. Stop selling this book. I give a 3 star instead of 2 because I respect Kent Beck and I know the books shortcommings is not a reflection of Becks shortcommings.
on December 12, 2007
Being a huge Kent Beck fan ..I pre ordered this book and was very excited to see what he had to say this time , but the excitement fizzled out only after a few chapters .
The book is about "back to basics " kind of topics and is extremely boring . You would have extremely hard time picking it back up once you put it down .
Pick up Fowler's Refactoring instead ( if you haven't already) if you are looking to improve your fundamentals .
on November 9, 2007
"Implementation Patterns" is a great book to make better Java developers. The focus is to make us think about writing more readable and maintainable code. Kent Beck accomplishes this by going thru WHY we write things a certain way.
The audience is Java developers who know the basics of the language. If you have more experience, you will understand points on a deeper level. If you are newer to Java, you will form good habits.
There were just too many things I liked about this book, so here's a list:
- clear, concise and short snippets
- simple, bare-bones diagrams
- discussion on caveats and tradeoffs
- over 100 pages of patterns
- over 75 patterns
- about concepts and OO; not a style guide
- focus on values like communication and simplicity
- section on cross cutting principles like minimizing repetition
- short sections (Kent says some chapters long, but 30 patterns in 30 pages has great subdivision)
- how JUnit 4 design decisions follow theses patterns
- Kent even got in a dig about Sun never removing deprecated code
- bibliography with a blurb from Kent on each title
- pattern index on inside back cover in addition to traditional index
The book can be read straight thru or used as a reference. It's short, light and easy enough that it can be read on an airplane. (and in this case, it was.) It's also organized enough to go back and read about the pattern relevant at the time.