Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Salut a tous.
DESOLE
je me rend compte que j'ecrie une grosse bourde (Je vais arreter le cafe
promis).
ren realite j'ai confendu avec le fait que l'expression t = new T() si l'allocation memoire reussie et que contrusteur emet une exception le compileteur fera en sorte de recuperer le memoire alloue et cela a l'aide de l'operateur delete, ce qui ne etre possible si ce dernier est non public.
mea coulpa
D'accord mais pourquoi vouloir a tout prix forcer les clients de ton code a faire comme le créateur a envie ? Si les gens veulent faire autrement c'est leur problème, si ca trouve ils peuvent trouver un facon de faire sympa qui n'était pas prévue au départ.Envoyé par VoidSeer
Moi je met rarement des truc en private à la place de protected, je vois pas pourquoi j'interdirai a quelqu'un de réutiliser mon implémentation sans se servir de l'interface si il veut dériver ma classe.
En ce qui concerne les destructeurs privés, as-tu lu mon précédent post ?
Si non, fais le. Si oui, dis moi quelle partie n'est pas claire.
Ensuite sur le fond, je ne suis absolument pas d'accord. Dans la conception et l'implémentation d'une classe il arrive que l'on fasse des choix qui rendent sa dérivation nulle et non avenue. Les développeurs ne font pas souvent l'effort d'interdire la dérivation via des mécanismes de protection dans le code, mais la documentation le stipulera.
Correction des balises par Miles
Saufq ue tu as prévu ton code pour fonctionner d'une certaine manière et les autres ne connaissent pas le mécanisme interne. Et là, si tu permets tout, qqn pourrait se décider à faire des choses qui vont tout faire planter, et ça, en tant que concepteur, tu le sais très bien. Ca peut arriver dans n'importe quelles conditions.
Je sui d'accord pour le coup du destructeur.
C'est sur le fond que je trouve cela limite. En C++ les gens passent beaucoup de temps a vouloir interdire des choses aux utilisateurs du code. Alors que l'utilitée première des mécanisme de protection comme private,protected est de renforcer la réutilisation de composant en exibant une interface indépendant de l'implémentation.
Je ne suis bien évidemment toujours pas d'accord. Lorsqu'un concepteur interdit la dérivation d'une classe c'est un choix volontaire qui découle de contraintes d'architecture ou d'implémentation. En théorie de la programmation orientée objet, cette possibilité a toujours existée. Si tu regardes un langage objet à but pédagogique comme Eiffel, le mot clef frozen sert justement à cela. En Java, le fait de déclarer une classe final fait la même chose. En Smalltalk, il me semble qu'il y a aussi quelque chose de similaire.
Ensuite, je ne vois pas en quoi forcer une classe à être une feuille d'un arbre de dérivation nuit au objectifs de la POO qui sont la modularité et la réutilisabilité. Le choix de l'implanteur est de forcer la réutilisation de la classe via une relation d'agrégation. Dérivable ou non, la classe exhibe toujours une partie interface et une partie implémentation. Si vraiment tu souhaites en étendre la fonctionnalité malgré le choix du concepteur, utiliser un patron du type Decorator résoud le problème.
J'ai suffisamment enseigné les langages objets pour affirmer que la sur utilisation de l'héritage est un des premiers travers du débutant éclairé. D'ailleurs, une de mes règles en matière d'architecture c'est de toujours privilégier la collaboration à l'héritage.
Argumente s'il te plait, car je ne vois vraiment pas sur quelles bases tu peux faire une telle affirmation.En C++ les gens passent beaucoup de temps a vouloir interdire des choses aux utilisateurs du code
Justement l'utilisation de ce patron requiere un sucroit de travail. Et je ne vois pas l'avantage a préférer la collaboration a l'héritage, si l'héritage te permet d'atteindre ton but plus simplement.
Le dév qui veut quand même réutiliser la classe est obligé d'utiliser le DP décorator pour contourner la limitation que tu lui impose. Si u développeur fait n'importe quoi en dérivant une classe c'est sa responsabilité, tu ne pourras de toute facon par le forcer a programmer correctement, juste l'empécher de faire une ou deux chose localisée.
C'est simple :
* Je pense qu'il faut systématiquement préférer protected à private. D'ailleur les langages que tu a cité ne propose pas d'équivalent a private (j'en suis pas sur pour smalltalk mais pour eiffel oui). Le but des protection est d'exiber une interface, le concept de protected est suffisant pour ca.
*A chaque fois que l'on déclare un méthode non virtual cela empéche un autre developpeur d'adapter l'objet a ses besoins. Le problème étant que le C++ demande au développeur a choisir entre la performance et l'adaptabilité.
PErsonnellement, je suis tout à fait d'accord avec VoidSeer, mais ce n'est que mon avis. L'héritage, c'est dangereux, très dangereux. On parle souvent de différence entre Is-A et Has-A. Si ta classe EST un autre type, OK pour l'héritage... public. Sinon, c'est de l'agrégation.
Une Chevrolet EST une voiture.
Une chevrolet A une radio.
Donner à la Chevrolet les caractéristiques par dérivation privée ou protected, puisque tu préfères, c'est pas forcément judicieux.
J'aime private. Pourquoi ? Parce qu'avec lui, je sais que personne ne touchera aux entrailles, pas même une classe dérivée. Au cas où qqn voudrait dériver, sans même prendre un accesseur, par exemple.
Grrr je me suis encore mal exprimé, je parlait uniquement des protections sur les données/méthodes. Les hériatges privé/protc/public c'est autre chose.
Le but de la programmation orientée objet est la modularité, la sécurité et la facilité de maintenance, sûrement pas le temps de développement. Dans la durée de vie d'une application, le temps de développement est mineur par rapport au temps de déboggage, validation et maintenance.
Si tu regardes la complexité et le temps induit par la (meta-)programmation template, tu verras que l'argument du temps d développement ne tient pas.
Le dev. qui fait n'importe quoi, je ne réutilise pas son code. Si je suis capable d'en hériter, j'y ai accès, donc je fais un copier/coller de ce qui m'interesse et je remet les choses d'aplomb.
Maintenant, le dev. qui pose une limite à l'utilisation de son code et qui la documente, je respecte son choix. Ne serait-ce que parce que lui a étudié le problème et qu'en conséquence il a posé ces limites.
Une erreur classique des étudiants que j'ai eu et des ingénieurs débutants que j'ai encadrés et de vouloir hériter des conteneur de la STL. Eh oui ! Ne t'en déplaise, la moitié des classes de la bibliothèque C++ la plus utilisée ne sont pas faite pour être dérivées...
Pour finir, si tu regardes n'importe quel bouquin d'architecture logicielle tu verras que préférer la collaboration à l'héritage est une règle d'or, ou au moins un principe à respecter
Tu penses mal.
1/ Une interface c'est la partie publique d'une classe, stricto sensu. Le but des protections c'est de cacher au client l'implémentation de l'interface et private est suffisant pour cela.
2/ private est justement utile dans une classe susceptible d'être dérivée pour garantir un comportement uniforme au sein de ce niveau d'abstraction
3/ Eiffel possède bien évidemment l'équivalent de private pour Smalltalk ça fait un bail que je n'ai pas pratiqué je ne m'avancerais pas. En revanche ADA possède aussi une section privée.
Une fois encore non. Justement dans la conception d'une classe apte à être dérivée, il faut parfois interdire la dérivation d'une partie des fonctions afin de garantir l'intégrité de la classe mère. Pourquoi crois tu qu'en JAVA où toute fonction membre est par défaut dérivable, on puisse interdire explicitement cette dérivation (méthode final).A chaque fois que l'on déclare un méthode non virtual cela empéche un autre developpeur d'adapter l'objet a ses besoins. Le problème étant que le C++ demande au développeur a choisir entre la performance et l'adaptabilité.
Loupé la protection maximale en Eiffel c'est tout ce qui est déclaré apres
Et dans ce cas une classe fille peut utiliser les méthode et données déclarée avec cette protection dans la classe mère. Cela correspond donc à Protected.
Code : Sélectionner tout - Visualiser dans une fenêtre à part Feature {}
Extrait de http://chl.be/glmf/www.linuxmag-fran...m8/eiffel.html
Maintenant si mégoter là dessus c'est ton seul argument...... la classe NONE est conceptuellement la classe la plus basse dans l'arbre d'héritage et "feature{NONE}" indique qu'aucune classe extérieure n'a visibilité sur ses primitives (équivalent de "private").
Donc donner à la Chevrolet les méthodes publiques de la radio, c'est bien? Non. L'héritage public, le plus utilisé n'importe comment, ce n'est que dans des cas très précis, selon le Liskov Substitution Principle.Grrr je me suis encore mal exprimé, je parlait uniquement des protections sur les données/méthodes. Les hériatges privé/protc/public c'est autre chose.
Ensuite, pour le problème private ou pas, protéger la classe mère, c'est important. Si on hérite d'elle, c'est qu'on doit fonctionner comme elle, donc il ne faut pas faire n'importe quoi.
Je n'ai jamais dis le contraire ?! Je sais faire le distingo entre aggrégation et héritage merci.
Je peux savoir pourquoi vous être aussi agressif ?
Concernant eiffel : si tu lis la page que tu m'a donné on peut trouver ça
je me permet, respectueusement de te faire remarque la fin de la phrase : ainsi que dans leurs descendants ce qui est donc plus proche que du protected que du private.- plusieurs sections "feature" qui contiennent les déclarations de primitives (méthodes et attributs). C++ et Java permettent de contrôler la visibilité de ces déclarations de manière rudimentaire : elles peuvent être "public" (visibilité et utilisation par toute autre classe), "private" (utilisables uniquement à l'intérieur de la classe où elles sont définies, ainsi que dans leurs descendants)
<blabla Eiffeil>
Ce qui est déclaré en 'feature{NONE}' en eiffel n'est pas accessible aux classes dérivées.
Par définition, les seuls objets qui y ont accès sont les instances de NONE et ça tombe bien, il est impossible d'en créer.
</blabla Eiffeil>
Maintenant, on peut ergoter sur des exemples pendant des lustres, mais le fond du pb demeure, le protected systématique n'est pas défendable, de même que l'abus d'héritage et la position qui consiste à dire que les membres ne sont pas tous virtuels uniquement pour des problèmes de performances.
Ce sont des discussions rempante que j'ai souvent avec des débutants, pour lesquel j'ai toute ma patience, mais rarement avec des personnes qui se réclament d'expérience, d'où le ton peut-être un peu incisif.
Maintenant, je pense qu'il y a assez de matière sur le web pour étayer mon propos. Si ce n'est pas le cas, je me ferais une joie de te recommender quelques ouvrages de référence.
Ca tombe bien les descendants n'ont pas besoin de créer d'instance de NONE puisqu'ils utilisent ces feature par héritage. Écoute je veux pas renter en conflit avec toi mais sur ce coup la tu t'es planté. Écrit deux classe eiffel tu verra que ca marche comme ca.
bref on va arréter ici.
J'ai vraiment l'impression d'être satan pour toi quand je lis tes message.
Balance 2-3 références cela cloturera la discussion. Et chacun pourra ce faire son opinion.
Bonne soirée.
Bon.
Mon point de vue. Bof de permettre à des utilisateurs de dériver à tout va.
Soit les points de variabilité dynamiques de la classe sont prévus dès le départ, et effectivement on pourra supplanter les fonctions membre qui nous intéressent. Soit ce n'est pas le cas, et là forcer l'héritage c'est casser des bouts du contrat initial. (souvenez-vous, un carré n'est pas un rectangle, tout ça). Arriver à s'inscruster de la sorte signifie généralement (de mon expérience) que du refactoring, même mineur, s'impose. Rajouter les virtual à la volée n'est plus un problème vu que l'on refactore justement la classe initiale (même combat pour ce qui est de rendre protected tel ou tel membre). Si la classe n'est pas à portée de notre refactoring, c'est qu'il nous faudra trouver une autre solution. Autre solution qui nous sauvera de bien des désagréments lors de la maintenance.
Nombre de classes où j'ai vu des virtual et autre protected utilisés à tout va. Tout ça pour ne montrer qu'une seule chose : que l'on n'a pas réfléchit à ce que cela signifiait. Parmi les divers exemples d'endroits où j'ai vu ça, (et pour lesquels j'estime que cela mérite une entrée au dailywtf) j'ai eu des singletons et des classes orientées valeur.
Dans le genre, sur un gros projet, je n'ai pas croisé un seul virtual "par défaut" qui me fut d'un quelconque intérêt. J'ai même plutôt eu tendance à les faire sauter pour clarifier les sémantiques et les points de variabilité.
Les classes à sémantique de valeur sont (par défaut) complètement incompatibles avec des hiérarchies polymorphes. De fait, aucun intérêt de laisser des virtual et des protected. C'est d'ailleurs le cas de tous les conteneurs de la SL.
Après, d'autres ont évoqué le LSP. Un exemple de wtf que je ressasse régulièrement, ce sont les listes triées dérivées de listes. On ne peut pas définir un seul type qui respecte tous les contrats de ces deux classes (comment permettre d'insérer n'importe quoi en plein milieu (parce qu'il y aura toujours une fonction attendant officiellement une liste pour faire cela, et que l'on sera tentés d'appeler), et de garder la contrainte de tri).
Bref, je n'aime pas cette vieille approche qui consiste à dire que l'héritage c'est fait pour réutiliser. On néglige, ce qui est à mon goût, son plus gros intérêt. En C++ on a la chance de pouvoir distinguer la substituabilité (LSP) (le plus gros intérêt, de mon humble opinion) de la simple implémentation-en-termes-de (ce qui est encore différent du "dispose-d'un").
Vous l'aurez compris, je suis plutôt un adepte du codage statiquement défensif. Je ne dois pas aimer les surprises tant que cela.
Mon Eiffel est rouillé, je te concède ce point. Néanmoins, le blocage volontaire de dérivation existe en Eiffel (comme Java et C++), vu qu'une feature peut-être déclarée "frozen", c-a-d non redéfinissable dans les classes dérivées.Ca tombe bien les descendants n'ont pas besoin de créer d'instance de NONE puisqu'ils utilisent ces feature par héritage. Écoute je veux pas renter en conflit avec toi mais sur ce coup la tu t'es planté. Écrit deux classe eiffel tu verra que ca marche comme ca.
Je m'y attèle ce WE si j'ai un peu de temps.Balance 2-3 références cela cloturera la discussion. Et chacun pourra ce faire son opinion.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager