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.