Quelles sont les règles principales et les plus importantes (avantages et inconvénients) que je dois appliquer lorsque j'écris une classe qui sera héritée par une tierce partie.
Merci.
4 Réponses :
La règle de base est la suivante: ici sont quelques plus bonnes directives pour la conception de la classe.
loin et loin la règle la plus importante. En fait, peut-être que la seule règle à part "n'expose pas les rétiaux de mise en œuvre". Le problème est que cela fait cela est exceptionnellement difficile, prend une tonne de connaissances de la part de l'écrivain de l'API et est très facile de vous tromper!
C'est une lutte quotidienne, mais ça vaut la peine :)
RÈGLES:
ne le faites pas. Évitez d'utiliser l'héritage dans la mesure du possible.
La classe doit avoir au moins une fonction virtuelle. Plus précisément, le destructeur doit être virtuel.
La classe devrait probablement être abstraite.
Lorsque vous dites virtuels, vous ne pouvez pas passer sans héritage
Je suis sur le côté "non" aussi. Beaucoup de programmation axée sur des objets apprises, mais ont complètement sauté la programmation d'objets. Ne fournissez pas aux classes 3ème parties à hériter - leur fournir des objets prêts à utiliser.
@Dummy: ce que vous appelez «Programmation d'objet» est plus largement appelé «Programmation basée sur des objets». (Et je suis complètement d'accord avec vous.)
Évitez certainement l'héritage lorsque vous le pouvez. Le plus grand barrage routier que je trouve dans la compréhension du code consiste à déterminer ce que les choses de classe sont vraiment quand il y a un arbre de héritage profond en jeu.
solide ... pris de (ou quel que soit votre arôme de l'acronyme du mois;) Htth andy
J'ai toujours désaccord avec S, ne trouvez pas o utile, ne pensez pas que la substitution a quelque chose à voir avec le design par contrat et ne pense pas beaucoup des deux derniers. Si je n'avais pas posté de réponse moi-même, ce serait un -1 de moi.
Ouais à chacun leur propre! Je suis tout pour s personnellement. C'est un peu semblable à «préférer des classes minimales aux classes monolithiques» et «donner une entité une responsabilité cohésive». Je trouve que cela aides au sida clarté, réutiliser et me permet d'être plus agile en combinaison avec "la composition préférée à l'héritage". Je trouve assez facile. Si l est un design par contrat est un peu non négligeant - c'est peut-être une forme extrême, mais je pense que cela résulte de "Traitement de la conception de la classe en tant que conception de type". Je peux imaginer que je sois utile, mais je n'ai pas écrit de code qui en a besoin moi-même. Je pense que D est très important pour les grands systèmes à long terme. 0.02C
Serait intéressé par des raisons spécifiques / problèmes avec les points. Pour le S - trouvez-vous qu'il est trop noir et blanc, ou pensez-vous que c'est complètement dans la mauvaise direction?
@Andy je pense que c'est faux. Prenez une classe de compte bancaire par exemple, je peux penser à au moins trois responsabilités sans lever de sueur. Aussi, avez-vous déjà utilisé des cartes CRC? Vous vous retrouvez avec une liste de responsabilités sur chaque carte.
@Neil quand vous dites: «Prenez une classe de compte bancaire», vous avez contourné la phase de conception de la classe, ce que c'est tout à propos de! Juste parce que la classe de compte bancaire que vous étudiez dans 'OOP avec Java 101' ne suit pas le principe de la responsabilité unique, cela ne signifie pas a la classe de compte bancaire ne peut ni, ni que ce ne serait pas ' t profit. (Pas que je suive des règles religieusement, l'esprit - je viens de trouver d'essayer de vous concentrer sur une seule responsabilité m'aide au jour le jour.)
Fait intéressant, il y a eu une discussion sur une liste de rubis récemment sur la conception et utilise des comptes bancaires comme exemple. Il faut un peu de digestion (pour moi au moins). C'est l'idée de James Coplien de données, de contexte et d'interactions (DCI). Les mails de Coplien sont blade.nagaokaut.ac.jp /cgi-bin/scat.rb/Ruby/Ruby-Talk/357461 , lame.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-Talk/357539 , BLADE.NAGAOKAUT.AC.JP/CGI-BIN/SCAT.RB/RUBY/RUBY-TALK / 357705 . Un article est Artima.com/articles/dci_vision.html .
@Andy je n'ai rien contourné quoi que ce soit. En fait, j'étais responsable de la rédaction de quelques cours de conception OO pour une entreprise de formation commerciale. L'une des conceptions Les cours utilisés étaient pour - vous l'avez deviné - un compte bancaire. Et je n'ai jamais étudié Java, 101 ou autrement. S'il vous plaît, n'essayez pas d'inventer des expériences pour moi - j'en ai assez de la vraie chose.
Devis: Un compte est une collection d'usages d'utilisation. ... Les vrais objets sont des journaux de transaction et des sentiers d'audit. Ils deviennent ré-configurés dans des interactions sur chaque cas d'utilisation, où les cas d'utilisation sont au niveau d'un objet contextuel appelé compte. À l'exception de ses références de ménage qui définissent le rôle de rôle / instance actuel au niveau de la piste d'audit et du niveau de transaction, le compte est apatride. Votre compte bancaire n'est pas un nombre assis en mémoire ou assis sur un disque quelque part, plus que votre argent est assis dans un sac sur une étagère dans une banque quelque part. C'est un calcul: un cas d'utilisation.
@ Neil - désolé, ne voulait vraiment rien offenser. Je pensais que vous avez choisi votre compte bancaire parce que c'est une place de départ commune sur les cours de l'OOP de ce que je rassemble et que nous imaginions tous les deux la même chose. Vous dites 'prendre une banque ... élever une sueur.' Cela me semble un argument circulaire, car vous concevez la classe vous-même (bien que tacitly, dans votre tête), puis dit qu'il ne suit pas un principe de conception, ergo le principe n'est pas le son. Ce que je veux dire, c'est juste parce qu'il est possible de concevoir une classe de compte avec de nombreuses responsabilités, cela ne signifie pas qu'il est impossible de concevoir un avec un seul
Je viens d'un contexte Java, les règles de l'héritage sont donc un peu différentes, mais voici mon point de vue:
En fait, l'héritage est facile si vous ne l'utilisez pas.
Conduire une voiture est facile si vous ne le faites pas. Apprendre quelque chose de nouveau est facile si vous ne le faites pas. La stagnation est la chose la plus facile à faire.
Apparemment, je suis le seul à avoir un peu de problème avec la formulation de la question ... Pouvez-vous clarifier "Sera hérité de tiers" si vous voulez dire (1) sera utilisé comme une classe de base par quelqu'un d'autre [peut sembler comme la signification évidente], (2) sera maintenue / prise sur par quelqu'un d'autre (jamais entendu le dicton "supposons que votre code sera maintenu par un maniaque homicide qui sait où vous vivez "?), ou (3) sera utilisé" tel quel " par une tierce partie.