Customer Reviews

Implementation Patterns

5 star:		(8)
4 star:		(6)
3 star:		(7)
2 star:		(4)
1 star:		(2)

 

 

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.

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.

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...

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.

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.

If you consider yourself a senior Java/OO developer, you won't gain much insight here. I found that I skimmed almost the entire book in a couple hours. One issue I had with the book is that it seemed where the conversation got slightly interesting or may have more to offer, the text dried up and moved on, where it may have been well-served by a code example.

This isn't too say that Beck's patterns aren't useful or well-advised, but the interested buyer should understand if the book will be useful, and this really depends on your skill and experience. In general, I think we could all benefit if everyone wrote more readable, maintainable, and flexible code.

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 .

"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.

-Motivation-

The author is Kent Beck. That alone merits at least a thumb-through of any book. Beck's self-described premise of this book is that "good code matters." He goes on to state his goal of showing us how to communicate ideas better in code.

-Cons-

This book tackles a subject that is not quite as crucial as some others. Beck says, "This book fits somewhere between Design Patterns and a ... language manual." I agree with him, but need to slide a few more in there after Design Patterns, and before this one. It's almost like a coding standard on crack. This doesn't make it bad, but it's basically in the back of the line of books that a good software engineer should read and understand.

-Pros-

As with most patterns books, this one shines a light on things that experienced developers have done for years, but maybe without thinking about why. Sometimes just being forced to think about these habits is valuable, even if you may not agree with the author's conclusions. Beck does a good job of giving us technical bits (the actual patterns) with values and principles used to guide the decision making.

One example of a pattern is Parameter Object. Here beck describes the practice wrapping parameter lists in objects and passing the composite object instead. This is something we've all done at some point for a few possible reasons. Beck just brings the issue to the forefront to make us think about when exactly to do this.

An example of one of the principles Beck uses as a guide is Symmetry. He tells us, "Symmetry in code is where the same idea is expressed the same way everywhere it appears in code." This guides us from naming variables to, say, consistently applying patterns like Parameter Object when our method parameter lists get too long.

-Summary-

This is a good book. But if I liken my bookshelf to shelf of different grit of sandpaper, this is a very fine grit: you should only use this after you've completed the coarser stuff.