Kent Beck

All,

Thank you for your stimulating questions and the discussions. I hope you enjoy and profit from Implementation Patterns. If you have further questions, I will continue to participate on http://groups.yahoo.com/group/implementationpatterns.

Regards,

Kent Beck
Three Rivers Institute

Michael,

I think there is more to it than that. For example, I look for multiple messages to the same object in a given method as a hint that the receiving object could use more responsibility. I don't do any fancy business analysis, I just pattern match. I think an automated tool could detect this pattern, but it would have to be fairly sophisticated:
for (X each : Y.Z()) {
Y.W();
}
for example, probably belongs in Y.

Regards,

Kent Beck
Three Rivers Institute

Dear Walter,

I am not familiar with IntelliJ's inspections. Assuming they are triggered by a kind of AST matcher, some of the patterns (or their absence) should be detectable.

Regards,

Kent Beck
Three Rivers Institute

Darya,

I recommend you read the book before concluding what's in it. I make the case for method comments there, although in some cases I find other techniques to be more effective for communication. The overall responsibility is clear: programmers are responsible for communicating with other programmers.

Regards,

Kent Beck
Three Rivers Institute

Darya,

I don't know anything about the SCJD program, so I can't comment based on any experience.

Regards,

Kent Beck
Three Rivers Institute

Ilja,

What I learned writing Implementation Patterns is how much language influences what idioms are appropriate. I started with the same outline and ended up with (it seems to me, I haven't measured) not very much overlap.

If I was writing the Smalltalk Best Practice Patterns again I would expand the scope to cover the patterns you use when the code base is going to get very large. Other than that I think the book stands up pretty well.

Regards,

Kent Beck
Three Rivers Institute

Originally posted by Michael Hunger:
[QB]Dear Kent,

thanks for your positive reply. Perhaps building a kind of online Implementation Patterns community with wiki like pattern collection (this was the thing Ward inventend the wiki for wasn't it?) would enable people with experience in the fields you can't cover to contribute?

*** That could be an interesting project. The challenge we've always had with shared pattern repositories is maintaining a consistent voice.

Regarding the collection example. The measurements you did are all correct. But the point you make about initializing sizes of collections is not covered by the tests of list operations. It is relevant for the build up of the collections which is not measured at all. (And there it may increase the time and memory needed manifold).

*** You are absolutely right. I need to remeasure and include some operations.

How do you see the implementation patterns? Do they stand alone at the lowest level or are the intricately immersed in the fabric of techniques used creating or changing code? So the question is: Would the references to the mentioned sources of these techniques help putting the patterns into context or disturb the reader while grasping them?

*** If Implementation Patterns were a scholarly work, it would make sense to track down all the antecedents (as some people have with, for example, pair programming). I have no idea where I learned most of the patterns, however, and Implementation Patterns is my personal perspective on programming. I can see the value of the implementation pattern equivalent of the Oxford Dictionary of the English Language, tracking down the first instances of the patterns.

What do you think about the intended audience of the book? And what should the (different?) types of people who read the book learn from it?

*** I wrote it to people who care about programming and care about communicating. I hope there is something there for programmers at every level of skill. I have seen some unintentionally ironic reviews from expert programmers who say, "This is all really beginner stuff, but the book pointed out that I consistently make the following mistake..."

*** Some people come to the book expecting wizard tricks, and they seem to go away disappointed. This isn't another Design Patterns where you can spend many happy hours understanding the details of the patterns. The patterns themselves are mostly pedestrian. Their effective application is what takes a long time to master.

What would be great is a course developed to teach the implementation patterns (the real pattern not just language syntax).

*** Thanks for the recommendation. I will certainly be writing a talk about the book. The best format for learning the patterns I know of is to sit down with someone and some code, talk about how the code does or doesn't use the patterns, retrofit the patterns that are missing, and reflect on the results. Unfortunately I don't know how to do that with 100 people at a time.

Regards,

Kent

Dear Gian Franco,

I haven't programmed in Ruby so I don't have personal experience. However, I have programmed for many years in Smalltalk. There are design thoughts I can express easily in Smalltalk that I can't in Java and vice versa. One aspect of Java I find frustrating is that there is seldom a short, sweet way of saying anything. By the time I have spelled out all the types and parentheses and for loops my one little thought has turned into four lines. I often find concise ways of expressing myself in Smalltalk, and from what I've seen of Ruby it is similar.

Fundamentally, though, communicating through code is a choice. I can program with an awareness of how people will read the code in any language.

Regards,

Kent Beck
Three Rivers Institute

Dear Walter,

Implementation patterns are partly different in different languages. What is considered a reasonable practice in Ruby would be sneered at in Java code. Sometimes this is because of the structure of the language, sometimes it stems from the prevailing culture around a language. The principles and values in Implementation Patterns work in any language and fundamental thesis, the importance of communicating with other people, does too.

The first book I wrote was The Smalltalk Best Practice Patterns, basically the same scope as Implementation Patterns but applied to Smalltalk. I started IP with the outline of the earlier book, but many of the patterns are quite different.

I chose Java because it is the lingua franca of programming at the moment and because I already knew Java. I can imagine writing a whole series of XXX Implementation Patterns books to explore the differences between languages, but that would be a different project.

Regards,

Kent Beck
Three Rivers Institute

Gabriel,

I'm not offended. Every author should be prepared to answer this question. You may find Implementation Patterns valuable if you would like to communicate more clearly through your code. The goal of clear communication may be personal satisfaction, improved teamwork, or reduced maintenance costs.

Does that answer your question?

Regards,

Kent Beck
Three Rivers Institute

Dear Kasper,

The focus of the book is on writing code so others can read and understand it. An example pattern is Composed Method which answers the question of how long methods should be. Methods should be composed out of other methods, each of which is at similar levels of abstraction (an example of the principle of symmetry).

These patterns are smaller in scale than design patterns, focused on relationships within objects rather than between objects.

Regards,

Kent Beck
Three Rivers Institute

Rogerio,

Implementation Patterns covers coding issues, so there is nothing in there specifically about web services. To the extent that you need to code to implement or use a web service, however, the book could be helpful.

Regards,

Kent Beck
Three Rivers Institute

Guys,

I'm sorry if I sounded high and mighty. I don't always get my code right and I can use help finding ugly spots. When I code in Smalltalk I use a tool called Smalllint. In Eclipse I use the built in code rules. For awareness of larger-scale issues I use Structure 101. My favorite technique, though, is pairing. If someone else understands what I'm writing, then I am usually on the right track.

Regards,

Kent Beck
Three Rivers Institute

Louis,

I agree with the other posters that Implementation Patterns are smaller scale than design patterns--intra- rather than inter-object. The book does discuss the values and principles behind the patterns, which is part of what makes it not just another Java style book.

Regards,

Kent Beck
Three Rivers Institute

Jatandar,

The patterns don't address optimization. Ken Auer and I wrote a paper called Lazy Optimization in "Pattern languages of program design 2" talking about performance.

As far as complex data structures, the patterns won't help directly but they will help you communicate your intentions in the resulting code. My bias, is to avoid the need for complex data structures but when I need one, I want it to be as easy to understand as possible since such structures often need to be changed.

Regards,

Kent Beck
Three Rivers Institute