J'ai de gros doutes quant à l'intérêt de cet article. L'auteur tente de vulgariser les design patterns en s'attardant plus sur des effets de bord que sur l'explication des concepts qui les sous tendent (ce qui est un comble lorsque l'on fait des rappels sur la conception objet).

A ce sujet, il vaut mieux se plonger dans le livre du gof qui outre le catalogue de modèles propose une introduction d'une trentaine de pages très abordables et enrichissantes. On y apprend entre autre que les design patterns ont vu le jour dans les années 70 grâce à un architecte nommé Alexanders et qu'ils adressaient des problèmes de construction de bâtiments.

Mon sentiment sur « les rappels de conception objet » :

Contrairement aux langages de type procéduraux comme le C ou le Pascal, la conception objet ne divise pas l'espace de données (attributs) et l'espace de traitements (méthodes). Cet espace commun s'applique à une partie du problème à gérer sous la forme d'une classe.
Donc en gros, la différence entre le paradigme objet et procédural se réduit à :
- en procédural, on a, d'un coté les données et de l'autre les traitements
- en objet, données et traitements sont fusionnés au sein d'un concept appelé classe

Une classe est une représentation abstraite décrivant comment faire fonctionner des objets.
Drôle de façon de voir les choses. Si "Alexandre" est une instance de la classe "Homme", la classe "Homme" décrirait donc comment faire fonctionner "Alexandre". Une classe définit une unité sémantique basée sur la statique (attributs et méthodes) et la dynamique (états) et c'est ce complexe statique-dynamique que l'on appelle le comportement.

Les objets sont construits à partir de cette classe lors de l'exécution par un processus d'instanciation (en Java l'opérateur new). Chacune des déclarations dans une classe peut être limitée dans sa portée (portée locale ou privée, portée de groupe ou package, portée de descendance ou protégée, portée globale ou publique).
Hors sujet par rapport à "Quelques rappels sur la conception objet"

Une classe peut être associée à d'autre classes pour faciliter la réutilisation.
Pas d'accord. Une classe doit être associée à d'autres classes de même niveau de granularité et même niveau d'abstraction sous peine de souffrir de manque de cohésion (l'un des facteurs de non-réutilisation)

L'association la plus commune est l'héritage.
Je ne pense pas : une relation d'association simple est beaucoup plus commune que l'héritage. Il suffit de s'interroger sur la nature des relations que l'on entretient avec notre environnement (réseaux de connaissances, possessions personnelles, etc.) pour s'apercevoir qu'il y a très peu de relations d'héritage.

L'héritage sert à spécialiser une classe existante (lien de généralisation/spécialisation) par la modification/l'ajout de nouvelles méthodes et de nouvelles données. Cette spécialisation conduit à la construction de nouvelles classes (appelées aussi sous-classes). Le concept d'héritage peut être vu comme la conception d'un élément "est une sorte de".
L'héritage doit être vu comme une relation "est une sorte de". Lorsque ce n'est pas le cas, il faut être capable d’expliquer pourquoi sinon, on va au devant de problèmes de conception et de non-réutilisabilité (que ce soit des modèles ou des implémentations).

Lorsqu'une méthode d'une classe est redéfinie par une sous-classe, on dit qu'il y a surcharge. Comme nous le verrons dans la suite cette possibilité donne une grande souplesse à l'introduction de classes génériques déléguant certains comportements aux sous-classes.
Je ne pense pas que le terme "classe générique" soit approprié. Une classe générique s'appelle, dans le méta model d'UML, « Parameterised Class » (les adeptes de C++ auront reconnu les templates).

Certaines classes ne sont pas complètement construites afin d'obliger les sous-classes à effectuer une surcharge. On parle alors de classes abstraites ou d'interfaces.
Encore une fois, c'est une drôle de façon de voir les choses. Si je décide que la classe "Mammifère" est abstraite, ce n'est pas pour obliger les sous classes à implémenter certaines méthodes mais plutôt parce l'on ne peut pas trouver d'individus de cette espèce qui ne soient que des mammifères.

L'interface est employée en Java pour compenser l'interdication d'utiliser l'héritage multiple (héritage de plusieurs classes), interdication qui n'apparaît pas en C++.
Bof. L'interface n'est un outil qui permet de "simuler" le multi héritage. La notion d'interface permet de donner à une classe une "empreinte" supplémentaire, cela relève plus du polymorphisme que du simple moyen de compensation. Il est a noter que même si le C++ autorise le multi héritage, il n'est pas préconisé d'en abuser (risque d'héritage en diamant,...) et en général, on fait en sorte d'hériter simplement d'une classe concrète et de multi hériter de classes abstraites. C'est ce genre de principe qu'ont appliqué les personnes qui ont créé Java.

Une interface est associée à une ou plusieurs classes d'implémentation.
Non, c'est plutôt le contraire : ce sont les classes concrètes qui sont en relation avec les interfaces (relire les specs d'UML à ce sujet). Une interface peut être en relation avec autre chose à partir du moment où le autre chose est une autre interface et que la relation est une relation d'héritage.

Une classe d'implémentation contient donc le code de réalisation de l'interface.
Je préfère dire que la classe qui dispose d'une nouvelle « empreinte » doit être équipée des méthodes qui lui permettent d'assumer sa nouvelle forme.

Dans la suite de l'article, nous proposerons des exemples en Java. Ces exemples sont facilement transposables en C++ ou dans tout autre langage objet.
Je ne vois pas ce que le reste de l'article apporte de plus par rapport au gof.