Tag Archives: livre

Comment utiliser les Design Patterns

Erich Gamma est l’un des co-auteurs du livre Design Patterns avec le “gang of four”, co-auteur de Junit avec Kent Beck ainsi que leader du projet eclipse sur la partie java… Eh oui ça le fait comme CV. Et quand Erich Gamma discute avec Bill Venners d’Artima ça donne un excellent papier.

“You really learn about polymorphism when you’ve understood the patterns. So patterns are good for learning OO and design in general”

100% d’accord. Il existe un fossé entre la programmation procédurale et la programmation objet qui est souvent bien difficile à franchir. Ce n’est tout simplement pas la même façon penser. Personnellement je ne connais pas de méthode 100% efficace pour faire “comprendre” l’objet. Mais la remarque d’Erich Gamma me semble tout à fait judicieuse. En y réfléchissant bien il me semble n’avoir vraiment eu le sentiment de bien maîtriser la “pensée” objet qu’après avoir découvert et appliqué les design patterns. Il est difficile de comprendre la puissance de l’objet car le polymorphisme, l’héritage, l’encapsulation… sont des concepts relativement abstrait. Appliquer un design pattern à un problème de code rend les principes de l’objet concrets.

D’autres remarques on ne peut plus pertinente sur les design patterns:
– Inutile de démarrer une conception en se disant je vais utiliser un maximum de pattern.
– Il vaut mieux adopter une démarche “refactoring to pattern”.
– Un design pattern, plusieurs implémentations possibles.
– La raison d’être des design patterns est la réutilisation et l’extensibilité
– Les design patterns fournissent un vocabulaire commun pour décrire et discuter d’une conception.

Il parle ensuite de la conception de Junit et de “pattern language”, et on attend la suite qui devrait être publié le 30 Mai…

Code et Commentaires

“Un code sans commentaire est un mauvais code,
un bon code n’a pas besoin de commentaire…”

Si je me souviens bien ça doit venir de The Pragmatic Programmer, une lecture hautement recommendable.

Je suis tombé sur ce billet qui illustre assez bien l’idée, plutôt que de mettre de tonne de commentaires dans le code pour respecter “les normes”, mieux vaux passer un peu de temps à refactorer son code pour qu’il n’y ait plus besoin de commentaire. Il est beaucoup plus dur (mais plus efficace aussi) de trouver les 3 mots qui vont former un nom de méthode explicite que de mettre 3 lignes de commentaires au dessus de doStuff().

Attention, je n’ai pas dis qu’il ne fallait pas de commentaires dans le code, mais juste la où il y en a vraiment besoin.

Books to read

Someone starting with J2EE ask me which were the books to read on the subject.
I’m sharing the answer with you. This is my list of must read book for J2EE developer

Best book to start with is definitely “Thinking in java” from Bruce Eckel. In this book you’ll find:
– A good introduction to object oriented programming
– How to use the most important java API
– Not only “how” but also “why” you should use them this way (most book fail on this part but Bruce Eckel is brilliant on the subject)

Java or not you can’t do Object Oriented programming if you don’t know the “Design Pattern” from the Gof. Everyone make references to “Design pattern”. You have to read it. Warning, this not an easy read. I try to read it again every year. With experience you get a better understanding of all those important patterns.
If you like design pattern (and you should) you can go on with “Core J2EE pattern” and “Patterns of Enterprise Application Architecture” From Martin Fowler.

Can’t recommend this book to beginners but if you have some experience with the java platform this is a must read: Rod Johnson “Expert One-on-One J2EE Design and Development”. I’ve been working with java for 5 years, this book synthesize most (and much more) of the things I have learnt during these years. I haven’t read his last book yet but I guess it’s also a gold mine. (“Expert One-on-One J2EE Development without EJB”)

Read these books and you’ll know why Martin Fowler, Bruce Eckel and Rod Johnson are call “guru”.
I could go on with more books to read but “Thinking in java”, “Design pattern” and “Expert One-on-One J2EE Design and Development” are my top 3. Got other books you feel are must read too? Let me know in the comments.

Refactoring

Enfin, je viens de finir de lire Refactoring de Martin Fowler, un livre de référence que je souhaitais lire depuis longtemps. Si vous vous demandez pourquoi dans le petit monde des serveurs d’application on n’arrête pas d’entendre Martin Fowler par ci Martin Fowler par là, lisez un de ses bouquins. Les sujets les plus complexes deviennent limpides.

Connaissant déjà bien le sujet ce livre ne m’a pas appris grand-chose. Mais ça ne fait jamais de mal de lire une explication claire de concepts que l’on applique habituellement sans trop y réfléchir. Il est particulièrement intéressant de voir comme les concepts énoncés dans ce livre (vieux de 5 ans) se retrouvent dans des outils comme Eclipse ou IDEA et font leur succès.

Au-delà d’un simple catalogue de techniques de refactoring ce livre contient beaucoup de retours d’expériences (entre autre Kent Beck). Expérience que l’on retrouve dans des chapitres tels que celui sur les tests unitaires (pourquoi les tests unitaires sont indispensable à un bon refactoring ) ou celui indiquant les “odeurs ” propre à un code qui a besoin d’être refactoré (méthode trop longue, nom de variable peu claire…).

Alors, si le menu refactoring d’Eclipse reste un mystère pour vous “Refactoring” est le livre à lire de toute urgence. Ne manquez non plus de faire une visite au site eponyme: refactoring