Envoyé par
koala01
Même pâs... Java et d'autres permettent de définir l'accessibilité des fonctions membres.
De manière assez différente, quand même. En particulier, en C++ accessibilité et l'héritage sont assez décorrélés. Essaye d'avoir une fonction privée virtuelle en C#, ce n'est pas possible. Donc le pattern de conception NVI est possible en C++ (et je l'emploie quasi systématiquement, et regrette généralement ensuite le "quasi"
, mais impossible dans C# (et probablement Java, mais je connais moins). Alors tu peux dire qu'il s'agit de détails de conception, et non de conception générale, mais tout de même...
Envoyé par
koala01
Mais on concevra de manière identique pour n'importe quel langage orienté objet: une conception pour C++ peut être utilisée pour java mais risque de nécessiter certains aménagement du fait des restrictions imposées par ce dernier.
Je suis assez fortement en désaccord là dessus. Comme le dit Coplien dans "Multiparadigm design for C++", il y a plusieurs façon possibles d'effectuer l'analyse de commonalités et de variabilité de l'espace du problème, et on peut trouver plusieurs jeux de dimensions différents, incompatibles, et a priori aussi valables les uns que les autres. Sauf qu'au moment de l'analyse de l'espace de la solution, certains choix vont être plus ou moins aisément mettables en œuvre dans le langage cible, et donc il recommande d'avoir une bonne idée de ces choix lors de l'analyse de l'espace du problème, afin de choisir le jeu de dimensions le plus adapté.
Si j'essaye d'être plus concret, en Java 1.4 ou en C#1.0, la bonne manière de designer des collections était un super-objet. Et il serait absurde si l'on sait que l'on doit travailler dans ces langages de faire une analyse à la C++ du problème (détermination des concepts auxquels doivent répondre les objets pour être membre d'un conteneur) pour finalement dire qu'avec des restrictions de ces langages, l'analyse ne sert à rien, puisque de toute façon, on n'a dans ces langages aucun outil qui manipule ces concepts. Il ne s'agit pas de dire que ces langages implémentent la même chose, avec des détails dont il faudra ne tenir compte que dans une phase ultérieure, mais que ces langages ont outils qui permettent de mettre en place des conceptions de nature fondamentalement différentes.
Envoyé par
koala01
Le DP composite, qui est la base des graphes, sera le même pour C++ que pour C# ou java.
Très bon exemple (j'aurais plutôt dit arbres que graphes, mais là n'est pas la question) ! En effet, un design en C++ va justement s'efforcer de s'éloigner de ce DP, pour revenir aux fondamentaux mathématiques de cette structure d'arbre, afin de fournir des algorithmes qui soient génériques, en se basant sur la notion de concept (et pas du tout sur des classes de base, ou de la POO). C'est ce que fait boost::graph pour les graphes, en s'abstrayant de savoir si on a une liste de nœud liés, une liste de liens vers d'autres nœuds, un tableau d'adjacence... Un tel
design n'aurait pas trop de sens en C#.
Envoyé par
koala01
Quand tu vois une fonction protégée ou privée, tu t'attends à ne pas pouvoir l'appeler d'une autre manière que... depuis une fonction membre de la classe (ou depuis une fonction membre des classes dérivées pour les fonctions protégées).
Ou depuis une fonction membre de la classe de base si cette fonction est virtuelle. J'insiste car c'est je pense le plus courant dans mes programmes. Il est très rare qu'une fonction virtuelle et privée soit appelée par une autre fonction de la même classe. Le plus souvent, une telle fonction dans le cadre du NVI est appelée depuis la fonction publique de la classe de base.
Envoyé par
koala01
Or, le fait de disposer de la fonction en accessibilité publique dans une classe de base retire justement cette restriction pourtant importante en permettant d'invoquer la fonction depuis... n'importe où, y compris depuis des fonctions qui ne sont absolument pas membres d'une classe intervenant dans la hiérarchie de classe.
C'est là que je suis en désaccord. On ne peut pas l'appeler depuis n'importe où. On peut l'appeler depuis les endroits où l'on sait que la classe dérive de la classe de base qui défini cette fonction publique.
Si une classe A implémente les interfaces I1 et I2, que I1 défini en publique une fonction virtuelle (ce qui est probablement un mauvais choix, dans le cadre d'un langage qui permet le NVI, mais un mauvais choix au niveau de la conception de I1. Si I1 est défini dans une bibliothèque, lorsque je fais la conception de A et I2, je dois vivre avec ce choix, et trouver la meilleure conception possible dans ce périmètre), mais que je souhaite que les gens qui manipulent directement A n'aient pas accès à la fonction, la définir privée dans la classe dérivée me semble un bon choix de conception.
D'autres langages définissent même des fonctionnalités spécifiques pour mettre ça en place, là où en C++ les règles générales marchent, ce qui semble vouloir dire que ce concept n'est pas si mauvais. Je pense par exemple au C# où il est possible de dire qu'une classe va implémenter explicitement une interface, c'est à dire qu'elle va redéfinir les fonctions (forcément publiques) de cette interface, sans pour autant que ces fonctions soient disponibles pour un utilisateur de la classe qui ne passerait pas par l'interface. Pour qu'un langage soit allé jusqu'à prévoir une syntaxe spécifiquement pour, on peut imaginer que le besoin existe, non ?
1 |
0 |
[Edit 3DArchi]
Notamment, cette de 1994 est beaucoup plus stricte que celle de 1988, qui ne se base que sur le comportement substitué (comportement, au sens contrat). La définition usuelle courante parle de propriétés - dont, grosse différence, le comportement ne fait pas partie. Ces propriétés, je les ai cité dans un post précédent, je les liste à nouveau ici : 
).
. Si on peut légitimement penser que LSP est respecté, je pense qu'on peut tout aussi légitimement penser qu'il y a (au moins dans 90% des cas) un problème de conception si on commence à changer la visibilité d'une fonction virtuelle dans les classes dérivées.