online shoes store xkshoes,here check the latest yeezy shoes click here.

know more about 2020 nike and adidas soccer cleats news,check shopcleat and wpsoccer.

Kurt Christensen Interviews Kent Beck about Implementation Patterns


April 2008

The Patterns

Q: Why patterns? Why not some other way to express idiomatic Java?

A: What I like about patterns is that they combine "what" and "why". So, in addition to talking concretely about what I do, like name variables after their role in a computation, I can talk about all the factors that readers might be interested in when encountering a variable.


Q: How would you describe the differences between "Implementation Patterns" and, say, "Effective Java" or "Practical Java"?

A: My goal in writing Implementation Patterns is to describe my approach to code, and in particular how I try to communicate with other people through code. I think this single-minded pursuit of a single goal is unique. I'm not trying to cover all of Java, or all of programming, I'm focused on the reader's experience of code and what the writer can do to enhance that.


Q: What are the costs of your implementation patterns, or are they too small for that? (I ask because it seems to me that the part of GoF that talks about patterns being a trade-off between flexibility and complexity isn't widely read.)

A: Once the patterns became habits for me it cost less to code with them than before. Before I always had a little debate going in the back of my mind when, for example, naming a variable. Once I had written "Role Suggesting Variable Name", I could focus on understanding the role and expressing it. In this, the Implementation Patterns don't come with the same kind of costs as design patterns. You have to name your variables. The different schemes don't vary widely in immediate cost.


Q: Is there an interplay between test-driven development and implementation patterns?

A: Yes in the sense of switching back and forth rapidly between them. Also, each test is a little story about the system, offering an outsider's view to complement the insider's view delivered by carefully written code.


Q: In your work with organizations, what are some common implementation anti-patterns that you see? More importantly, at the coding level, what are some of the most common negative values and principles?

A: What I work hardest on is removing larger scale complexity that people put in when they are focused on smaller scale decisions. After a period of such accretion it is almost always possible to find duplication or the use of techniques that are more complicated than needed.

Values in Coding

Q: In chapter 7 ("Behavior"), you state: "Aesthetics engage more of your brain than strictly linear logical thought. Once you have cultivated your sense of the aesthetics of code, the aesthetic impressions you receive of your code is valuable feedback about the quality of the code." How does your sense of aesthetics in code relate to your values of coding? (Or should we just direct readers to "Zen and the Art of Motorcycle Maintenance" ? :-))

A: Motorcycle Maintenance is certainly a good place to go for inspiration about the relationship between people and technology. I find motivation in aesthetics. Last week I was programming with a visitor and we were refactoring some complicated logic. Over and over he said, "There. That's much better." and I said, "No, it still isn't right." By the time we were done the code was much cleaner. The next day I sent him a message about how we could further simplify it. On the other hand, it's also important to know when good enough is good enough. At one point during our lunch break I just went away, staring off into space. I was feeling, physically feeling, how to manipulate the code to make it simpler. I love that feeling. A week with a few of those moments in it is deeply satisfying to me. I think this is a deeper sense of values than the
short list in the book.


Q: Does your coding style inform your thoughts on "agile" values, principles and practices? Or vice versa, perhaps?

A: I think they come from similar motivations, to try to master programming and put it in service of something larger.


Q: Later in chapter 7, you wrote "Back in the old days of programming, a commandment was issued: each routine shall have a single entry and a single exit... this bit of programming folklore, thoughtlessly obeyed, prevents the use of guard clauses." Is this a symptom of a larger issue? Do you think that our industry and academia fail to tell a good story to the software development community about values and principles?

A: I think so, which is why thinking in patterns is valuable.


Q: In your presentation "Ease at Work", you talk about programmers finding a level of comfort with their capabilities; who they are, and what they do for a living. How does this relate to working with implementation patterns on a minute-by-minute basis in your daily work?

A: Having chosen my patterns for myself I am at ease with my programming style. Because they help me communicate with other people, I am more at ease with my place on my teams.

Coding for Frameworks

Q: In chapter 10  ("Evolving Frameworks"), you explore some of the interesting differences involved with supporting common code. Specifically, you begin the chapter by stating "[These] implementation patterns assume that changing code is cheap compared to understanding and communicating the intent of code. However, framework development...violates this assumption." Considering this, in your experience have you found internal enterprise framework or service bus initiatives to be more expensive than they're worth?

A: They can be valuable or a disaster. The key principles I follow are to create frameworks from experience, use them early in their life, and find ways to continue evolving them. That final chapter addresses how to code to minimize the cost of future evolution. Early in the commercial application of objects I saw lots of "big framework up front" projects that either didn't finish at all or didn't effectively support applications.


Q: In "Evolving Frameworks" you state "A metaphor that has served us well in JUnit is to look at a framework as the intersection of all the useful functionality in a domain rather than the union... It's tempting to try and solve a broad range of problems with a framework. The conflict is that the added functionality makes the framework that much more difficult to learn and use for all clients." Has this happened to Java? Is it inevitable for technologies to drown themselves slowly in a sea of complexity?

A: I don't think plification (PL/I-ification) inevitable. It takes courage, principles, and perspective to say no. It's relatively easy to see the value of yet another feature. Without principles and perspective it's hard to see the accumulating cost of this feature with all the features that have been added already and how it affects options for future features. I believe in a punctuated equilibrium rhythm of change. If you drop a single grain of sand at a time onto a pile and count the number of grains of sand that move as a result of each addition, you will find a power law distribution. Most of the time only a few grains move. Every once in a while an avalanche results. In programming languages, the avalanches are the arrival of new languages--you can't easily implement the next feature without a complete change of context. That's when Erlang arises, or Ruby, or Haskell.