aspose file tools*
The moose likes Agile and Other Processes and the fly likes Implementation Patterns - Things I missed Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Implementation Patterns - Things I missed" Watch "Implementation Patterns - Things I missed" New topic
Author

Implementation Patterns - Things I missed

Michael Hunger
Greenhorn

Joined: Dec 17, 2007
Posts: 6
I excitingly awaited the book and was eager to read it. Reading it had two effects.

First a warm comfortable feeling of being at home (as Christopher Alexander tells us, feeling is very important to see if a pattern is alive). Many of the patterns Kent presents are an important part of my everyday developer life.

The second thing were the many thoughts that were provoked by the book. And these are the ones I'd like to show here to ask for other opinions and perhaps Kent's answer.

Having the patterns structured more (e.g. by intent) would had helped to conceive the language they form. Perhaps smaller chapters focused to some subtopic of the current chapters.

What I missed most in the book were _references_ (not necessarily discussion) at the different patterns to the other important works in this context, developing software even at the language level is never isolated from the other forces and possibilities one has. The concepts I mean are listed below:
* OO-Paradigm concepts (e.g see ObjectMentor)
* Patterns (Alexander)
* Refactoring(s) (Martin Fowler)
* Design patterns (GoF, POSA, Hillside)
* Testability / xUnit Testing (Kent, Erich Gamma, Gerard Meszaros)
* Java Language Spec (JLS - Gosling , EJ - Bloch)
* more explicit inter-references between the implementation patterns
* Concurrency (Brian Goetz)
* Code Reading (Spinellis)
* Pragmatic Programmers Tips (AndyHunt, PragDave)
* POSA5 (communication aspect of patterns) (Kevlin Henney, Frank Buschmann, Doug Schmidt)
* Domain Driven Design (Eric Evans) and the importance of language and structure

Things I missed most were:
* discussion of package concept, its usefulness for communication, structuring, documenting and visibility
* a consistent example carrying through the book, either from the JUnit library or an extended version of the Performance Measurement appendix
* Generics: used in many examples but not explained and no implementation patterns for them
* Enum: very shortly discussed in the framework section but imho belong to the class and interface chapter, very important as type-safe alternative to constants, the constant object would be an important accompanying concept
* Annotations although you use them in examples and have surely used them a lot in JUnit
* the immutable java.lang.*; objects which are the counterparts of the primitive types
* going with that Autoboxing, its many advantages and problems together with varargs
* more finger-pointing on potential concurrency problems, e.g. when sharing state, safe copy and the like
* regarding to communication: principle of least surprise - consistent usage of patterns throughout an application and commonly accepted usage of language features (e.g. java naming schemes etc).
* the danger of having overridable methods called in constructors
* an explicit Chapter on Properties, e.g. published, encapsulated attributes, the pro and cons, problems with published fields, with a discussion of the Java-Beans concept
* within the "Creation" Chapter a discussion on dependencies and dependency handling (publish them don't publish them, the creational patterns shown)
* discussion of Martin Fowlers POJO notion
* taking the language created by a framework or library further to the point where it covers its (small) domain -> further reading Martins DSL book (see http://martinfowler.com/dslwip/)
* how to handle cross cutting concerns ? use a technology for this or provide the hooks yourself
discussion of Inversion of Control, using callbacks to transfer the flow of control to a framework having my own code executed in a certain context/environment (especially resource handling etc)
* a more positive discussion of the final keyword (esp. for fields, locals, parameters) , it communicates a lot, helps to prevent a lot of errors (compiler catches them) and assures immutability
(declaring classes and methods final is a very different side of the coin)

A problem I had with the Appendix (Performance Measuring) example is that it ignores some advice of the book, contains minor bugs and some incorrect assumptions.

The statement that initializing collections with a size doesn't not matter is not correct. If you use the MethodTimer to measure the creation and filling of the collections you see that it increases the time and memory needed up to sevenfold.

Thanks alot for the book and the experience contained in it.

Michael Hunger
http://jexp.de
Kent Beck
author
Ranch Hand

Joined: Nov 07, 2003
Posts: 45
Dear Michael,

Thank you for the clear list of topics I didn't cover. Some of them I don't feel qualified to comment on. Others seemed to me less important than what is in the book (I work hard to keep my books approachably short). Some of them I really should have covered and didn't (see http://www.threeriversinstitute.org/TwoMoreImplementationPatterns.htm for two examples).

As far as the data in the collection section, I took that directly from measurements on my laptop. I tried not to make any claims about the universality of the data, but rather encourage people to go an find out for themselves.

I have saved your list of topics for a future edition of the book. Again, thanks.

Regards,

Kent Beck
Three Rivers Institute
[ December 18, 2007: Message edited by: Kent Beck ]

Author of <a href="http://www.amazon.com/exec/obidos/ASIN/0596007434/ref=jranch-20" target="_blank" rel="nofollow">JUnit Pocket Guide</a>
Michael Hunger
Greenhorn

Joined: Dec 17, 2007
Posts: 6
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?

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

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?

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?

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

Yours truly

Michael
Kent Beck
author
Ranch Hand

Joined: Nov 07, 2003
Posts: 45
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
Michael Hunger
Greenhorn

Joined: Dec 17, 2007
Posts: 6
Dear Kent,

thanks for the elaborate reply.

I don't think that pattern books are wizardry at all. As they collect living (implicit) experience and skill, most practitioners will find most of their own thoughts there. But giving this knowledge a name and some explanation and an recommendation when and how to apply it is tremendously helpful in coaching, teaching, reflecting.

Regarding collecting the antecedents. If Christopher Alexander is right, patterns for building are there since mankind made their first own structures. Perhaps this is the same with implementation patterns. Building structures, give names and create abstractions to help communicating is there since the dawn of programming. And as living patterns are the successful one they are repeated over and over again.

On the mailing list you coined the notion of your "style" as the trinity (communication, simplicity, flexibility) you support with the patterns listed. But I think this is more than just your style. These patterns contribute to the "elements of style" for writing code that adheres to these values and has the qualities we all long for to see in our code. I remember when reading "Refactoring" back in 2000 the notion of code that speaks to me (and others) stroke me like an enlightenment. This was it I strove for all the years and what gave me the ultimate satisfaction when reading code that has these qualities (which occurs seldomly enough).

What would a living Oxford English Dictionary look like? An annotated program / library where all the occurrences of the patterns are explained and walked through?

But getting back to the ground. Regarding the coursework. It is certainly not as efficient as coaching people individually in small groups (up to 5). But I could imagine having good and bad exercises working through them refactoring them to the patterns taught and giving the attendees the chance for failing and feedback would be a good start for such an (interactive) course even with larger groups. Perhaps relying on the group dynamics and the cooperation within the group (help them to help themselves) would help as well.

I don't think the patterns in the book are beginners stuff. They are part of the essence of what we are daily doing in our work (or should do). And no one is there already. Or have you seen the perfect program?

Thanks for all

Michael
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Michael Hunger:
I don't think that pattern books are wizardry at all. As they collect living (implicit) experience and skill, most practitioners will find most of their own thoughts there.


That's my experience, too. When I read the GoF book for the first time, I often caught myself thinking "well, this is just polymorphism in action, isn't it". Still, I learned a lot (and still am learning when thinking about the patterns). I also know a lot of people who don't get what's so great about the Strategy pattern.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Implementation Patterns - Things I missed