Dear Sudarshan,

Thank you for the question. The key skill is being able to quickly shift
perspective between the sending object, each of the receiving objects, and
an overall view of the computation. Practice reading complex code. Make
notes as you read. Draw diagrams of where the messages could be going.
Refactor code to replace conditionals with choosing messages. This will help
you indentify them when you see them.

I have cc'd the Implementation Patterns mailing list. You may want to
subscribe if you are exploring the book further.

Regards,

Kent Beck
Three Rivers Institute

-----Original Message-----
From: sudarshang@... [mailto:sudarshang@...] On Behalf Of
Sudarshan Gaikaiwari
Sent: Monday, February 04, 2008 3:19 PM
To: kent@...
Subject: Implementation Patterns Question

Hi Kent

I would like to thank you for your wonderful book "Implementation Patterns".

On page 66 you mention

"Reading code that uses lots of choosing messages requires skill to learn.
One of the costs of choosing messages ..."

Could you point to some pointers on how this skill can be acquired?

Thanks
Sudarshan

--
Sudarshan Gaikaiwari
www.sudarshan.org
sudarshan@...

All,

InfoQ has published a video interview with me about Implementation Patterns:
http://www.infoq.com/interviews/beck-implementation-patterns

Enjoy,

Kent Beck
Three Rivers Institute

All,

I am participating in a discussion of Implementation Patterns on Java Ranch
this week.
http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=forum&f=42. You
are welcome to join there.

Regards,

Kent Beck
Three Rivers Institute

This is an internal DSL embedded in Java using Method Chaining and
Grammar interfaces.

Please see Martins Fowler DSL-Book (Work In Progress) at:
http://martinfowler.com/dslwip/

Michael

On Sun, December 16, 2007 18:28, ironwaist29 wrote:
> First all I just finished reading IP and I loved it a great book
> focussing on things that are truly important.
>
> I have a question about a style of coding I encountered in the Guice
> dependency injection framework http://code.google.com/p/google-guice/ that
> I found fascinating and hope you would comment on it here is an
> excerpt
>
> binder.bind(Service.class) .to(ServiceImpl.class)
> .in(Scopes.SINGLETON);
>
>
> It seems that that you could almost form a English sentence coding this
> way is this a good style to use why or why not ?
>
> Troy Taillefer
>
>
>


--

First all I just finished reading IP and I loved it a great book
focussing on things that are truly important.

I have a question about a style of coding I encountered in the Guice
dependency injection framework http://code.google.com/p/google-guice/
that I found fascinating and hope you would comment on it here is an
excerpt

binder.bind(Service.class)
       .to(ServiceImpl.class)
       .in(Scopes.SINGLETON);

It seems that that you could almost form a English sentence coding this
way is this a good style to use why or why not ?

Troy Taillefer

Kent,

In the XP book you continuously use metaphors to describe the ideas behind
the values, principles and practices and derive lots of insight from
there.

Besides choosing metaphors for naming, I couldn't find explicit references
to metaphors for implementation. When (again) thinking about possible
metaphors for this one.

The only metaphor that is close enough and so powerful I can't even
comprehend half of its power is creative writing. There you use a language
to create a domain (world) habited by your key players who have a detailed
character, possess (dynamic) behavior, attributes and belong to
stereotypes. Besides the main characters which often form hierarchies
there are additional supporting people which get work delegated.

Communication between the characters acting in different roles and bearing
according responsibilities is very important.

When writing and telling your story, communicating with your reader is
most important, overwhelming them is not very useful. Careful choosing of
structures, names, building a consistent view of the world and the
processes therein makes the plot readable or unintelligible.

The argument that object orientation resembles the concepts of our world
and so writing is just a view or model of our world is not enough. When
writing you create new worlds where everything is under your control. Of
course most of these worlds resemble ours in many ways but don't have to.
They have to accommodate the story that is told within their realm.

The value of flexibility is needed when you extend your world and tell
more stories in sequels. Then it matters how you formed your world which
details did you publish prematurely and which ones remained hidden to be
refined later.
You even have the possibility to change your world, to evolve your
characters to let them die or have others take their roles and
responsibilities.

To break up hierarchies, to use new languages to introduce new situations
and events.

Although the book itself is not changed, the story it tells and the world
that it describes is changed afterwards.

Quite similar to updating an API or framework. You have to be consistent
(to some account) but the changes are neither forbidden nor a bad thing at
all. They are an evolution.

While creating your world you start with a outline, with some thoughts,
even some existing details, perhaps some requirements and incrementally
form this place, inhabit it and make it alive (players, behavior, roles,
etc.).

You constantly refine it until there is no unnecessary duplication, all
story-lines form together a consistent, understandable whole.

When is writing done? When the story is told, is there such a thing?

So, our writing is called writing software, theirs writing stories. Not so
different? What do you think ?

Michael

Kent,

clever :). Yes I understand it, it was only confusing that outside the
book the Java language was not mentioned. But it is focused of
communicating its intent through the language.

I agree with you that these values (communication, simplicity,
flexibility) are the most important ones for this purpose - in this order.

I just would have liked a kind of globally applicable set of values that
cover the realm of software development (but perhaps this would be to
abstract or general). The concrete principles derived for my environment
then guide the choice of practices I use.

Have you come up with a term that describes this trinity in one word?


Thanks,

Michael

On Wed, November 28, 2007 4:30 pm, Kent Beck wrote:
> Michael,
>
>
> My intention was that Implementation Patterns use Java in the same way
> that Design Patterns used C++. The whole value system and most of the
> patterns work directly in other languages. Some are specific to Java. If
> the general approach of communicating through code becomes popular, I can
> imagine writing a series of Implementation Patterns in C#/Ruby/PHP/...
>
> My value system while in the act of coding is more focused than it is
> when developing in general. That's why the values are different. It's not
> that I don't want to be respectful--when pairing it's critically
> important. It's that within the scope of this book, respect isn't as big
> an influence on my decisions as are simplicity, flexibility, and
> communication.
>
> Regards,
>
>
> Kent Beck
> Three Rivers Institute
>
>
> _____
>
>
> From: implementationpatterns@yahoogroups.com
> [mailto:implementationpatterns@yahoogroups.com] On Behalf Of Michael
> Hunger
> Sent: Monday, November 26, 2007 3:36 PM
> To: implementationpatterns@yahoogroups.com
> Subject: [implementationpatterns] Introduction & First notes
>
>
>
>
> Dear Kent & list members,
>
>
> after getting IP last tuesday, reading and rereading it over the last
> couple of days I feel now fit to comment on it. First of all I want to
> thank Kent for sharing his experiences and allowing us to reflect the
> things we do and rethink daily decisions.
>
> I shortly repeat my introduction that I already sent to Kent (sorry for
> that).
>
> I bought the book for several reasons. The first is having the
> opportunity to share the many experiences you made as developer,
> consultant, teacher, writer, speaker and last but not least as Agitar
> fellow. You have written and seen code that keeps to these values and was
> part of successful applications.
>
> I want to reflect the way I'm currently doing things and learn from the
> experience of others. Second I wanted some great material for bringing the
>  essence of good implementation practice to my fellow developers. When
> coaching I mostly build on my own knowledge and experience and I'd like
> to have more material to support my approaches. I've been developing Java
> software for 11 years now. It is fascinating which way Java took during
> these years and how many tremendous people contributed to its popularity.
>
>
> While reading the book there were so many things that came to my mind so
> that writing them down produced a quite lengthy review of the book.
>
> Kent invited me to join this list to have a lively discussion about the
> book. I originally wrote the review directed to Kent and I hope you forgive
> me not rewriting the adressing.
>
> If I'm to blunt please excuse it. My wife told me that German and
> American
> culture differ there quite a lot.
>
> Review: Implementation Patterns
>
>
> The first thing I noticed was, that nowhere in the title and on neither
> front nor back-cover the word Java appears. Just in the introduction you
> state that these implementation patterns " are Java programming habits".
>
> If one reads the TOC it becomes obvious that the Java language was the
> language of choice for deriving these concrete implementation patterns.
>
> Perhaps possible subtitles could have been
> * Communicative, Simple and Flexible Java (in memory of Effective Java)
> * Writing Readable/Intelligible Java Code
> * Java Best Practices
>
>
> If I bought the book without being a Java programmer I would be a bit
> disappointed, as there are other OO-languages with different facets that
> could also be used and supported by Implementation Patterns. I also think
>  that concentrating on concrete Java helps the applicability but
> abstracting the patterns enough to be easily applicable to other
> languages would have been helpful. Perhaps this is a task for an online
> community.
>
> I don't know where to start. So I start at the beginning and carry
> through to the end of the book. The things I missed are listed at the end
> of the review.
>
> The discussion of values, principles and patterns/practices is well known
>  from the XP books. I would like to ask why you excluded: Feedback,
> Courage and
> Respect from the values as these are also conveyed in the implementation
> patterns you describe. Especially respect to the people who use, read,
> modify and extend your code and the courage for removing unnecessary
> flexibility or breaking traditions. The feedback aspect is missing a bit
> as you mainly take the role of the developer who's writing the code and
> not the ones who read, use or change it.
>
> By the way as this trinity of read, use and change together with the
> values appears that often in the book, it would be great if there would be
>  a single synonym for that. I already thought about it but got no real
> answer. The closest thing would be: human oriented programming :)
>
> Michael
>
>
>
>
>
>


--

Dear Kent & list members,

after getting IP last tuesday, reading and rereading it over the last
couple of days I feel now fit to comment on it. First of all I want to
thank Kent for sharing his experiences and allowing us to reflect the
things we do and rethink daily decisions.

I shortly repeat my introduction that I already sent to Kent (sorry for
that).

I bought the book for several reasons. The first is having the opportunity
to share the many experiences you made as developer, consultant,
teacher, writer, speaker and last but not least as Agitar fellow. You have
written and seen code that keeps to these values and was part of
successful
applications.

I want to reflect the way I'm currently doing things and learn from the
experience of others. Second I wanted some great material for bringing the
essence of good implementation practice to my fellow developers. When
coaching I mostly build on my own knowledge and experience and I'd like to
have more material to support my approaches. I've been developing Java
software for 11 years now. It is fascinating which way Java took during
these years and how many tremendous people contributed to its popularity.

While reading the book there were so many things that came to my mind so
that writing them down produced a quite lengthy review of the book.

Kent invited me to join this list to have a lively discussion about the
book. I originally wrote the review directed to Kent and I hope you
forgive me not rewriting the adressing.

If I'm to blunt please excuse it. My wife told me that German and American
culture differ there quite a lot.

Review: Implementation Patterns

The first thing I noticed was, that nowhere in the title and on neither
front nor back-cover the word Java appears. Just in the introduction you
state that these implementation patterns " are Java programming habits".

If one reads the TOC it becomes obvious that the Java language was the
language of choice for deriving these concrete implementation patterns.

Perhaps possible subtitles could have been
* Communicative, Simple and Flexible Java (in memory of Effective Java)
* Writing Readable/Intelligible Java Code
* Java Best Practices

If I bought the book without being a Java programmer I would be a bit
disappointed, as there are other OO-languages with different facets that
could also be used and supported by Implementation Patterns. I also think
that concentrating on concrete Java helps the applicability but
abstracting the patterns enough to be easily applicable to other languages
would have been helpful. Perhaps this is a task for an online community.

I don't know where to start. So I start at the beginning and carry through
to the end of the book. The things I missed are listed at the end of the
review.

The discussion of values, principles and patterns/practices is well known
from the XP books.
I would like to ask why you excluded: Feedback, Courage and
Respect from the values as these are also conveyed in the implementation
patterns you describe. Especially respect to the people who use, read,
modify and extend your code and the courage for removing unnecessary
flexibility or breaking traditions. The feedback aspect is missing a bit
as you mainly take the role of the developer who's writing the code and
not the ones who read, use or change it.

By the way as this trinity of read, use and change together with the
values appears that often in the book, it would be great if there would be
a single synonym for that. I already thought about it but got no real
answer. The closest thing would be: human oriented programming :)

Michael

All,

Thank you all for your help in reviewing Implementation Patterns. If you
haven't received your complimentary copy please let me know.

I would like to shift the discussion on this group to the actual book and
open up membership to anyone. I hope you will stick around for what promises
to be a lively discussion.

Regards,

Kent

Can someone (presumably the author) fill in the blank:

"By reading the book 'Implementation Patterns', the reader will ____".

In other words, what is the goal of the book?

Thanks!

    - Steve Metsker