Kevin Kofler (./80) :

momotte (./75) :
tiens, exemple, toujours dans ton article:

What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.

--> wtf...

Sur ce point, je dois défendre l'article, pour moi ce qu'il veut dire est tout à fait clair.

En revanche, pour en revenir à l'exemple des carrés et des rectangles: si j'ai bien compris, la solution proposée par l'auteur de l'article et aussi par JackosKing est d'avoir une classe abstraite AbstractRectangle qui définit des fonctions getHeight, getWidth, getArea, ..., mais pas de setters, puis d'avoir une classe Rectangle et une classe Square qui dérivent toutes les 2 de AbstractRectangle et proposent les bons setters. Cette méthode est valide et va fonctionner correctement, mais il y a un grand problème: si Rectangle a été développé sans penser à l'ajout successif d'une classe "carré" (comme le présuppose justement l'article à plusieurs endroits), alors il n'y aura certainement pas la bonne classe AbstractRectangle et donc on se retrouve à devoir changer toutes les utilisations de const Rectangle * en const AbstractRectangle * (idem pour les références), il faut donc retoucher tout le code (même si on utilise un remplacement global automatique, ça implique quand-même de tout recompiler), c'est la galère.

Cette modification est minime par rapport à produire le code que tu as proposé qui va t'apporter énormément de problème dans le futur. Je me permets d'ailleurs de te signaler le fait que ton code ne sera plus compatible tout comme le mien avec ton cas. En effet l'utilisateur de cette classe ne peut pas avoir la responsabilité d'utiliser les setters sur H et W.
Tu dois alors utiliser une IDP (ce qui est proposé).

Sous la notion de "est-un" se cache des contrats qui doivent être respectés. Le refactoring de codes est d'ailleurs bien plus facile lorsque l'on respecte certaines bonnes méthodes de la POO.

Nil> Il ne s'agit pas de tout savoir à l'avance, mais de pouvoir modifier le code facilement.

Pour les desgin patterns, je pense que c'est pas la peine d'insister. Restez dans vos bidouilles et le refus d'apprendre si vous voulez... mais vous resterez toujours à un niveau faible en POO (on vous demande peut être pas plus?).
C'est quand même curieux de lire aucune publication sur ce sujet, c'est même assez prétentieux de les critiquer et de prétendre tout connaître. Ces méthodes ont inspiré la STL, le java le C#... sur les sujets de design pattern et design by crontract.

(NB: KK tu me déçois un peu de ne pas t'intéresser à ce sujet, qui est pourtant relativement important (au moins par curiosité, et donc pour faire des critiques un peu plus constructives )