Sur les interfaces et les classes abstraites :
J'irais plus loin que toi. Je pense que l'interface est le terme "objet" pour désigner un type abstrait, quelque chose qui est au moins aussi vieux que l'objet. Un type abstrait, c'est une catégorie de "machins" qu'on peut manipuler pour construire un algorithme. Pour définir un type abstrait, on fait en gros la liste des opérations disponibles sur les "machins" en question. Bien sûr, actuellement on parle objet, donc on ne dit pas "machin", mais objet. Mais bon, sur le fond c'est la même chose. Effectivement, comme C++ ne possède pas la notion d'interface, on l'implante en ce langage par une classe abstraite. A ce niveau, d'ailleurs tu fais une erreur. De fait en C++, une classe abstraire permet justement de représenter la notion d'interface et permet donc plus de chose que le partage de code.
Pour distinction entre récupération de code (héritage au sens classique des langages objets) et celle de type, je pense que la meilleure chose est tout simplement de ne pas appeler la deuxième héritage. Effectivement en Java une interface peut hériter d'une autre, mais c'est de l'implantation. Au niveau de la conception, il s'agit d'une relation sur les types abstraits : on définit un type abstrait dérivé à partir d'un autre type (c'est la notion de sous-typage de Sather). Ce genre de construction dépasse largement le cadre de la programmation objet. C'est utilisé par exemple dans les schémas XML.
sur la définition de DP
Là, je ne suis pas d'accord avec toi. Certains DP sont justement écrits pour faciliter la réutilisation de code (sans parler d'héritage). C'est le cas par exemple de la plupart des DPs de structure qui permettent d'adapter un code existant pour l'utiliser à partir d'un autre code existant. Bien entendu, il n'y a pas de magie : utiliser du code C++ dans une appli Java c'est lourdingue.
sur le Singleton
Alors là, non ! Un Singleton pur, c'est une seule instance, mais tout le monde comprend quand on parle de Singleton pour désigner une classe qui contrôle son nombre d'instances, même si ce n'est pas exactement un (je pense aux pools de Thread, par exemple).
D'autre part ta phrase "Une classe sans état est une classe qu'on n'instancie pas (modifiant static en java)." ne veut pas dire grand chose. Il existe effectivement (en Java) des classes qu'on n'instancie pas. Ce sont de "fausses" classes, c'est-à-dire des groupes de méthodes de classe (celles qui ont le modifieur static), c'est-à-dire une sorte de petite bibliothèque (je pense en particulier à la classe Math qui joue le rôle en Java de math.h en C). Je pense que l'auteur voulait parler dans son article d'objet sans état, c'est-à-dire d'objet sans variable. Par exemple quand on construit un Comparator en Java (un ordre), il est très classique que celui ni ne contienne pas de variable. L'objet joue alors le rôle d'un pointeur sur fonction orienté objet (et d'ailleurs, on utilise souvent une classe anonyme pour programmer ça en Java). L'objet est bien entendu instancié !
[^] # Re: Hum... [première partie]
Posté par boubou . En réponse à la dépêche Comprendre les Design Patterns. Évalué à 8.
Sur les interfaces et les classes abstraites :
J'irais plus loin que toi. Je pense que l'interface est le terme "objet" pour désigner un type abstrait, quelque chose qui est au moins aussi vieux que l'objet. Un type abstrait, c'est une catégorie de "machins" qu'on peut manipuler pour construire un algorithme. Pour définir un type abstrait, on fait en gros la liste des opérations disponibles sur les "machins" en question. Bien sûr, actuellement on parle objet, donc on ne dit pas "machin", mais objet. Mais bon, sur le fond c'est la même chose. Effectivement, comme C++ ne possède pas la notion d'interface, on l'implante en ce langage par une classe abstraite. A ce niveau, d'ailleurs tu fais une erreur. De fait en C++, une classe abstraire permet justement de représenter la notion d'interface et permet donc plus de chose que le partage de code.
Pour distinction entre récupération de code (héritage au sens classique des langages objets) et celle de type, je pense que la meilleure chose est tout simplement de ne pas appeler la deuxième héritage. Effectivement en Java une interface peut hériter d'une autre, mais c'est de l'implantation. Au niveau de la conception, il s'agit d'une relation sur les types abstraits : on définit un type abstrait dérivé à partir d'un autre type (c'est la notion de sous-typage de Sather). Ce genre de construction dépasse largement le cadre de la programmation objet. C'est utilisé par exemple dans les schémas XML.
sur la définition de DP
Là, je ne suis pas d'accord avec toi. Certains DP sont justement écrits pour faciliter la réutilisation de code (sans parler d'héritage). C'est le cas par exemple de la plupart des DPs de structure qui permettent d'adapter un code existant pour l'utiliser à partir d'un autre code existant. Bien entendu, il n'y a pas de magie : utiliser du code C++ dans une appli Java c'est lourdingue.
sur le Singleton
Alors là, non ! Un Singleton pur, c'est une seule instance, mais tout le monde comprend quand on parle de Singleton pour désigner une classe qui contrôle son nombre d'instances, même si ce n'est pas exactement un (je pense aux pools de Thread, par exemple).
D'autre part ta phrase "Une classe sans état est une classe qu'on n'instancie pas (modifiant static en java)." ne veut pas dire grand chose. Il existe effectivement (en Java) des classes qu'on n'instancie pas. Ce sont de "fausses" classes, c'est-à-dire des groupes de méthodes de classe (celles qui ont le modifieur static), c'est-à-dire une sorte de petite bibliothèque (je pense en particulier à la classe Math qui joue le rôle en Java de math.h en C). Je pense que l'auteur voulait parler dans son article d'objet sans état, c'est-à-dire d'objet sans variable. Par exemple quand on construit un Comparator en Java (un ordre), il est très classique que celui ni ne contienne pas de variable. L'objet joue alors le rôle d'un pointeur sur fonction orienté objet (et d'ailleurs, on utilise souvent une classe anonyme pour programmer ça en Java). L'objet est bien entendu instancié !