Les Design Pattern doivent être compris et manipulés avec aisance par tout développeur objet qui se respecte. Aujourd'hui nous focalisons nos regards sur le Design Pattern Observateur.

Nous entamons aujourd'hui une série d'articles traitant des Design Pattern les plus courants. Mais avant tout, que sont donc les Design Pattern ? On pourrait traduire Design Pattern par modèle de conception, ou schéma de conception. Ces modèles décrivent des solutions types pour répondre à des problèmes apparaissant de façon récurrente dans la conception des logiciels. Ces modèles ne sont pas apparus du jour au lendemain dans le monde de la programmation objet. L'expérience accumulée dans la résolution de problèmes récurrents, ainsi que les leçons tirées des erreurs, ont amené les programmeurs à formaliser de "bonnes pratiques" ayant fait leur preuves sur le terrain. Ces bonnes pratiques, ce sont les Design Patterns. Il en existe de nombreux, accompagnés de quelques principes de conception judicieux. Un programmeur objet se doit de connaître au moins les plus courants car ils seront autant d'outils à sa panoplie et ils lui éviteront de réinventer la roue en permanence. Cela ne veut pas dire qu'il faille les appliquer aveuglément en toutes circonstances. Un développeur doit avant tout réfléchir. Cette réserve faite, les Design Pattern sont une aide inestimable. Parce qu'ils ne sont que de bonnes pratiques, les Design Pattern ne dépendent pas d'un langage particulier. Tout langage objet ou orienté objet permet de les appliquer. Nous pourrions utiliser Squeak, Delphi, C++ pour ne citer que ceux là. Cependant, nous choisissons Java et / ou C# pour nos exemples parce qu'ils sont largement connus et qu'ils ne demandent pas d'alourdir le code avec la gestion des ressources comme peut l'exiger C++. Le lecteur trouvera nos exemples sur le Cd-Rom ou sur notre site www.programmez.com.