Préférez la composition au cours de l'héritage?

Pourquoi préférer la composition au cours de l'héritage? Ce compromis, il y a pour chaque approche? Quand devriez-vous choisir d'héritage sur la composition?

  • Voir aussi la classe dont le design est mieux
  • Il y a un bon article sur la question ici. Mon opinion personnelle est qu'il n'existe pas de "meilleur" ou "pire" principe de conception. Il est "approprié" et "l'insuffisance" de la conception de la tâche concrète. En d'autres termes - je utiliser à la fois l'héritage ou de la composition, en fonction de la situation. L'objectif est de produire de plus petites code plus facile à lire, de réutilisation et de s'étendre plus loin.
  • en une phrase l'héritage est public, si vous avez une méthode publique et de la changer ça change de la publication de l'api. si vous avez de la composition et de l'objet composé a changé, vous n'avez pas à changer votre api.
InformationsquelleAutor Readonly | 2008-09-08
  1. 1101

    Préfèrent la composition au cours de l'héritage comme il est plus malléable, facile à modifier par la suite, mais n'utilisez pas de composer toujours. Avec la composition, il est facile pour un changement de comportement à la volée avec l'Injection de Dépendances /Setters. L'héritage est plus rigide que la plupart des langues ne permet pas de tirer de plus d'un type. Si la chair est plus ou moins cuit une fois que vous dérivez de TypeA.

    Mon test à l'acide pour le ci-dessus est:

    • Ne TypeB souhaitez exposer l'interface complète (toutes les méthodes publiques ni moins) de TypeA tels que TypeB peut être utilisé là où TypeA est prévu? Indique Héritage.

    par exemple, Un Cessna biplan, va exposer à l'interface complète d'un avion, si pas plus. De sorte que le rend apte à tirer de l'Avion.

    • Ne TypeB veux seulement certains/une partie du comportement exposés par TypeA? Indique un besoin d' Composition.

    par exemple, Un Oiseau peut-être besoin que la mouche comportement d'un Avion. Dans ce cas, il est logique d'en extraire une interface /classe /les deux et en faire un membre de ces deux classes.

    Mise à jour: Viens de me remettre à ma réponse et il semble maintenant qu'il est incomplet sans la mention expresse de Barbara Liskov de Principe De Substitution De Liskov comme un test pour " Devrais-je être héritent de ce type?'

    • Le deuxième exemple est tout droit sorti de la Tête d'Abord, les Modèles de Conception (amazon.com/First-Design-Patterns-Elisabeth-Freeman/dp/...) le livre 🙂 je recommande fortement ce livre à toute personne qui a été googler cette question.
    • Il est très clair, mais il peut manquer quelque chose : "Ne TypeB souhaitez exposer l'interface complète (toutes les méthodes publiques ni moins) de TypeA tels que TypeB peut être utilisé là où TypeA est prévu?" Mais si cela est vrai, et TypeB également exposer l'interface complète de type c ? Et si type c n'a pas été modélisé encore ?
    • Vous faites allusion à ce que je pense devrait être le plus fondamental de test: "Si cet objet d'être utilisable par le code, qui prévoit que les objets de (ce serait) le type de base". Si la réponse est oui, l'objet doit hériter. Si non, alors il devrait probablement pas. Si j'avais tenait qu'à moi, les langues doivent fournir un mot-clé pour voir "cette classe", et de fournir un moyen de définir une classe qui doit se comporter comme une autre classe, mais pas substituables pour elle (par exemple une classe aurait tous "cette classe" références remplacé par lui-même).
    • "Cessna biplan, va exposer à l'interface complète d'un avion" ne ressemble pas à une bonne analogie pour moi, et me fait penser à "carré-rectangle problème". Est "avion" ici, un résumé de la classe, celui qui ne vole pas et n'a que quelques spécifications sur le papier? Je préfère penser que l'héritage des exemples comme: "RedToyota < UnpaintedToyota < ToyotaChassis".
    • le point est " puis-je passer dans un Cessna biplan à tous les clients qui attendent un avion sans l'effet de surprise?'. Si oui, alors les chances sont que vous voulez l'héritage.
    • merci pour la clarification. Cependant, mon avis est qu'un producteur ne peut pas construire un "avion", mais un producteur peut construire un châssis Toyota. Donc, "avion" ressemble ici il sert comme une classe abstraite, qui est comme une "interface" pour le client. J'essayais de penser à une bonne analogie de l'héritage de prêt-à-utiliser des classes. J'ai entendu dire que la programmation orientée objet trouve son origine dans une tentative de modéliser les états et changements d'états de la vie réelle des objets, mais l'OMI dans la vraie vie, il n'a pas de sens de dire que les Bus et Moto hériter de MotorVehicle.
    • À propos de l'avion de l'analogie, je préfère: CessnaBiplanePilot < PilotSchoolStudent.
    • Je suis effectivement du mal à penser à des exemples où l'héritage aurait été ma réponse, je trouve souvent de l'agrégation, composition et les interfaces résultat en plus des solutions élégantes. De nombreux exemples ci-dessus peuvent éventuellement être mieux expliquées à l'aide de ces approches...
    • votre commentaire est une bonne façon d'expliquer comment faire le bon choix. Si vous ne pouvez pas modifier le type de l'objet une méthode accepte, alors vous êtes obligés de la sous-classe. Sinon, la composition est préféré.
    • votre exemple d'échec de l' "est un" test: RedToyota n'est pas un ToyotaChassis, donc RedToyota ne devrait pas hériter de ToyotaChassis. De même, CessnaBiplanePilot "est un" PilotSchoolStudent est également faux.
    • Ryan: je pense que cela dépend de ce que l'on entend par "est un" (pouvez-vous donner une définition formelle?). Un carré est un rectangle, mais, dans certains contextes, vous ne pouvez pas hériter Square de Rectangle (en.wikipedia.org/wiki/Circle-ellipse_problem). Je ne suis pas convaincu que, sans plus de précisions "est un" est un test significatif.
    • Je peux dire que RedToyota est un ToyotaChassis avec quelques trucs en monticule sur elle (que je ne peut pas le besoin). Et je peux dire que CessnaBiplanePilot sait au moins autant que d'une moyenne PilotSchoolStudent, et pourrait prendre des notes ou de passer des examens à sa place.
    • Je pense qu'il n'y a pas de controverse sur la définition de "qui est" un test, il est censé signifier "A est une (sorte de) B". Qu'est-ce que controversée est de savoir si ou de ne pas "Carré est un Rectangle" dépend de ce que vous entendez par le Carré et le Rectangle. Celui que vous avez correctement défini les propriétés que vous voulez à partir d'un Carré et d'un Rectangle, le Cercle Ellipse problème aura une solution évidente.
    • Je ne vois pas dans quel sens "est un" est moins controversée que "si le carré est un rectangle". Un carré est un rectangle, mais probablement une mutable carré n'est pas une mutable rectangle. Si quelque chose "est un" autre chose dépend de la façon dont il est destiné à être utilisé, sinon, je ne vois pas comment il serait possible de dire qu'une structure de données EST un autre (différent) de la structure de données.
    • Dans le 2ème exemple: N'aurais-je pas il suffit de créer une classe d'avions de combats, et la sous-classe avec Avion et l'Oiseau? Je ne vois pas où la composition rentre dans cet exemple.
    • que faire si l'Oiseau avait déjà à la sous-classe des Vertébrés ? Même si le langage permet l'héritage multiple - elle se traduit généralement par une messier type de conception
    • Permet de parler de la vraie vie qui, de temps à autre, je rememeber. J'ai besoin de retourner les données de formaté façon. Comme array('status' => 'succès', 'data' => $données$). Je veux avoir ce format en un seul endroit et donc je l'ai dans la fonction. Maintenant, je alwayws ajouter une classe, puisque la dépendance pour cela d'une fonction. Mais de nombreuses dépendances sont mauvais, de sorte que la suce. Donc, je pense que je pourrais ajouter cette fonction à la classe parent. Mais je ne comprends pas à partir de Biplan - Avion exemples. Puis-je hériter et comment pourrais-je appeler la classe de base alors? Peut-être juste "BaseClass" et c'est ça?Dois-je utiliser toutes les méthodes de la classe de base de l'enfant?
    • Un RedToyota a-a ToyotaChassis (mais ne peut pas); un RedToyata a-a Châssis, qui peut ou peut ne pas être un ToyotaChassis. Un RedToyota est pas un bon exemple parce qu'une Voiture a une couleur, et une marque. Et, bien sûr, il y a l'inévitable voiture volante discussions. Composants de l'INTERFACE utilisateur sont toujours parmi les meilleurs exemples de l'héritage disponibles.
    • C'est un grand livre, mais les Canards exemple semble cassé. Même si ils ont utilisé à la composition, à la fin de la RubberDuck classe encore est Duck, et comme telle, elle souffre encore d'une structure rigide. Le FlyNoWay de la classe vide fly() méthode est la même que pour un vide fly() à une mauvaise utilisation de succession dans la première place. Cela peut également constituer une violation de la LSP, depuis les clients de tous les Duck objets vont s'attendre à performFly(). Un canard en caoutchouc qui ne performFly() de ne pas avoir été déplacés, par exemple, et le client peut s'attendre à un canard de ne pas être dans le même endroit après le vol.
    • vous ne savez pas si cette déclaration est généralement applicable pour déterminer si une classe doit hériter de - Ne TypeB souhaitez exposer l'interface complète (toutes les méthodes publiques ni moins) de TypeA tels que TypeB peut être utilisé là où TypeA est prévu? Indique l'Héritage Par exemple, si j'ai de la classe Rectangle et je veux de la couleur rouge rectangle. Je ne devrais pas créer RedRectangle hérite de Rectangle. Il est plus comme le Rectangle doit composer classe de Couleur. N'est-ce pas ?
    • Mon problème avec cette réponse, c'est qu'il prétend "mais n'utilisez pas de composer toujours l'approche" sans expliquer pourquoi. Dans mon expérience dans le domaine Bancaire, CRMs, document Numérique, la gestion de l'Héritage est toujours un obstacle indésirable qui doit être remaniée en sortir. Parce que notre "classifications", sont toujours trop naïf & ne correspondent pas à la réalité. Même les biologistes ont se plaint de taxonomie hiérarchique. L'héritage est bon seulement avec les interfaces, dans ce cas est juste de la bonne ole ad hoc polymorphisme dans d'autres langages comme Haskell.

    InformationsquelleAutor Gishu
  2. 381

    Pense de confinement comme un a un relation. Une voiture "a un moteur, une personne "a un" nom", etc.

    Penser à l'héritage comme un est un relation. Une voiture "qui est" un véhicule, une personne "est un" mammifère, etc.

    Je ne vais pas prendre le crédit pour cette approche. Je l'ai pris directement à partir de la Deuxième Édition de Code Complet par Steve McConnell, la Section 6.3.

    • Ce n'est pas toujours parfaite, c'est tout simplement une bonne ligne de conduite. le Principe de Substitution de Liskov est beaucoup plus précis (échec de moins).
    • Ne pouvez-vous pas convertir la plupart des est une pour a relations? D'où une voiture a une basicVehicle objet et une personne a un basicMammal objet, etc.
    • "Ma voiture est un véhicule". Si vous considérez que comme une phrase distincte, et non pas dans un contexte de programmation, qui n'a absolument aucun sens. Et c'est tout l'intérêt de cette technique. Si il semble maladroite, il est probablement faux.
    • Bien sûr, mais "Ma Voiture a un VehicleBehavior" a plus de sens (je suppose que votre "Véhicule" de la classe pourrait être nommée "VehicleBehavior"). Si vous ne pouvez pas baser votre décision sur les "a" vs "est une" comparaison, vous devez utiliser LSP, ou vous allez faire des erreurs
    • Au lieu de "est" penser "se comporte comme." L'héritage d'hériter de comportement, pas juste de la sémantique.
    • comme" peut être réalisé via des interfaces sans la nécessité pour l'héritage. Wikipedia: "Une mise en œuvre de la composition au cours de l'héritage commence généralement par la création de diverses interfaces représentant les comportements que le système doit faire preuve d'une...Ainsi, le système de comportements sont réalisés sans héritage."
    • Oui, et c'est ce que le commentaire précédent est vraiment à la mendicité pour. Mais cette question est à propos de l'héritage, et quand nous étendre une classe, nous ne hériter du comportement de la mère. C'est tout ce que je dis. Bien sûr, l'interface doit être préférée à l'héritage.
    • Ceci ne répond pas à la question. La question est "pourquoi" et non pas "quoi".

    InformationsquelleAutor Nick Zalutskiy
  3. 200

    Si vous comprenez la différence, c'est plus facile à expliquer.

    Code De Procédure

    Un exemple de ceci est PHP sans l'utilisation de classes (en particulier avant de PHP5). Toute logique est encodé dans un jeu de fonctions. Vous pouvez inclure d'autres fichiers contenant les fonctions d'assistance et ainsi de suite et la conduite de vos affaires de la logique par le passage des données autour de dans les fonctions. Ceci peut être très difficile à gérer, car la demande augmente. PHP5 essaie de remédier à cela en offrant plus de la conception orientée objet.

    Héritage

    Cela encourage l'utilisation des classes. L'héritage est l'un des trois principes de OO design (héritage, polymorphisme, encapsulation).

    class Person {
   String Title;
   String Name;
   Int Age
}

class Employee : Person {
   Int Salary;
   String Title;
}

    C'est l'héritage au travail. L'Employé "est" une Personne ou hérite de Personne. Toutes les relations d'héritage sont de type "est-un" relations". Employé également ombres le Titre de propriété de la Personne, sens de l'Employé.Le titre sera de retour le Titre de l'Employé n'est pas la Personne.

    Composition

    Composition est privilégié par rapport à l'héritage. Pour faire très simple, vous auriez:

    class Person {
   String Title;
   String Name;
   Int Age;

   public Person(String title, String name, String age) {
      this.Title = title;
      this.Name = name;
      this.Age = age;
   }

}

class Employee {
   Int Salary;
   private Person person;

   public Employee(Person p, Int salary) {
       this.person = p;
       this.Salary = salary;
   }
}

Person johnny = new Person ("Mr.", "John", 25);
Employee john = new Employee (johnny, 50000);

    Composition est généralement "a un" ou "un" de la relation. Ici, l'Employé de classe a d'une Personne. Il n'hérite pas d'une Personne mais il récupère à la Personne objet passé en elle, c'est pourquoi il "a une" Personne".

    La Composition au cours de l'Héritage

    Maintenant, imaginons que vous vouliez créer un type de Gestionnaire si vous vous retrouvez avec:

    class Manager : Person, Employee {
   ...
}

    Cet exemple fonctionne correctement, cependant, que si la Personne et Employé à la fois déclaré Title? Devrait Manager.Le titre de retour de "directeur des Opérations" ou "Monsieur"? En vertu de la composition de cette ambiguïté est mieux géré:

    Class Manager {
   public string Title;
   public Manager(Person p, Employee e)
   {
      this.Title = e.Title;
   }
}

    Le Gestionnaire d'objet est composé comme un Employé et une Personne. Le Titre comportement est pris de l'employé. Cette explicites composition supprime l'ambiguïté entre autres choses, et vous rencontrerez moins de bugs.

    • Pour l'héritage: Il n'y a pas d'ambiguïté. Vous êtes à la mise en œuvre de la Gestionnaire de la classe en fonction des besoins. Donc, vous seriez de retour "directeur des Opérations" si c'est ce que vos exigences spécifiées, sinon vous suffit d'utiliser la classe de base de la mise en œuvre. Vous pouvez également faire une classe abstraite et, ainsi, assurez-vous que le bas-classes de flux de mettre en œuvre un Titre de propriété.
    • Il est important de rappeler que l'on pourrait dire "la Composition au cours de l'héritage", mais cela ne veut pas dire "Composition toujours plus de l'Héritage". "Est-un" héritage et conduit à la réutilisation de code. Un employé est une Personne (le Salarié ne dispose pas d'une personne).
    • Vous devez savoir au moment de la création de la classe de personne que vous voulez être en mesure de changer ce que signifie le titre, résumé les propriétés sont un signe d'une mauvaise conception, le comportement devrait être abstrait, pas l'état.
    • L'exemple est source de confusion.Un employé est une personne, de sorte qu'il devrait utiliser l'héritage. Vous ne devriez pas utiliser la composition pour cet exemple, parce que c'est à tort relation dans le modèle de domaine, même si, techniquement, vous pouvez le déclarer dans le code.
    • Voici plus d'informations sur la composition des implémentations (et des limites): stackoverflow.com/questions/554145/...
    • J'aime assez cet exemple, parce que, si un Employé est à la fois un Gestionnaire et un et un Agent. Dans les environnements où vous ne pouvez pas hériter de plus qu'une classe, vous avez un problème et que vous la plupart du temps les données en double. Avec la composition que vous pouvez gérer cela d'une manière élégante. Et la charge est minime, même dans les milieux où l'héritage multiple est possible, je préfère cette solution.
    • Les Classes ne sont certainement pas nécessaires pour composer des choses ensemble. En effet, les classes souvent prévenir composition en cachant le composable bits à l'intérieur d'une application spécifique des wrappers.
    • c'est tout de même pas que bon un exemple: un meilleur modèle serait qu'un Employé est une Personne, mais il a un Rôle à jouer.
    • C'est la même idée. Un Employé est en quelques sorte un rôle. Je suis un Employé, mais je suis aussi un Père. Donc, assurez-Employé et Père d'un Rôle et de composer avec la même Personne.
    • Je suis en désaccord avec cet exemple. Un Employé est Personne qui est un cas d'école de la bonne utilisation de l'héritage. Je pense aussi que le "problème" de la redéfinition du champ de Titre ne fait pas de sens. Le fait que des Employés.Titre ombres Personne.Le titre est un signe d'une mauvaise programmation. Après tout, ils sont des "Monsieur" et "directeur des Opérations" vraiment se référant à l'aspect d'une personne (en minuscules)? Je voudrais renommer Employé.Titre, et ainsi être en mesure de référencer le Titre et JobTitle attributs d'un Employé, ce qui fait sens dans la vie réelle. En outre, il n'y a aucune raison pour que le Gestionnaire (suite...)
    • (... suite) pour hériter de la fois la Personne et l'Employé -- après tout, Employé déjà hérite de Personne. Dans des modèles plus complexes, où une personne pourrait être un Gestionnaire et un Agent, il est vrai que l'héritage multiple peut être utilisé (bien!), mais il serait préférable, dans de nombreux environnements d'avoir un résumé du Rôle de la classe à partir de laquelle le Gestionnaire (contient les Employés s/il gère) et de l'Agent (contient les Contrats, et d'autres informations) héritent. Puis, un Employé est une Personne qui a de multiples Rôles. Ainsi, à la fois la composition et l'héritage sont utilisés correctement.
    • Exemples classiques sont souvent mal - après tout, les manuels de simplifier la réalité autant qu'ils le peuvent, de se concentrer sur un concept-clé à la fois. Et il semble que vous n'avez pas lu les précédents commentaires, qui montrent pourquoi, il peut très bien être la mauvaise relation - et ceux-là ne sont pas un peu bizarres valeurs aberrantes, c'est le genre de problème que vous voyez dans presque tous les types d'application. J'ai effectivement utiliser l'héritage de moins en moins au fil du temps - il n'a tout simplement pas tout à fait semblent de payer le loyer pour la plupart de la conception. Liskov Substitution de Principe semble être le meilleur "retour-de-la-main" rapide décideur dans mon expérience.
    • J'ai re-lu les commentaires précédents, et ne comprends pas ce que vous pensez est le problème avec mon modèle de relations. Aussi, en "manuel", je voulais dire "conforme ou correspondant à une norme ou à un type qui est prescrit ou largement détenu par les théoriciens", pas "une interprétation littérale des manuels scolaires". Comme dans, si la meilleure façon de décrire la relation entre A et B est "Un est un type spécial de B", alors la plupart des gens acceptent l'héritage est l'approche la plus appropriée à la situation.
    • Mais si les salariés est Personne dépend de votre domaine et overal de conception. Comme netiul noté, il peut être beaucoup plus pratique pour l'Employé d'être rôle de la Personne (c'est à dire "la Personne est un Employé, Gestionnaire, Fils de rôle"). Que faire si vous êtes à la fois Agent et Manager? Ou votre Gestionnaire est une Société? Faites votre théoriciens de recommander l'utilisation de l'héritage comme cela dans une langue qui ne supporte pas l'héritage multiple? Exemples classiques ont généralement un contexte dans lequel elles ont du sens; beaucoup d'articles écrits sur l'héritage assumer plusieurs l'héritage possible (et souhaitable).
    • OK, j'étais en supposant que le logiciel était une sorte d'employé système de gestion. Bien sûr, si vous voulez un très générales modèle capable de gérer tous les aspects des personnes et de leurs actions, alors vous auriez besoin de faire une classe de Personne (ou quelque chose de plus général?) avec des (très général) Rôles et toute sorte d'attribut d'une Personne pourrait éventuellement avoir. Ici, la composition est évidemment supérieure. Mais dans de nombreux systèmes du monde réel, vous avez une beaucoup plus simple (et mieux défini) le modèle de la complexité de l'être dans le fonctionnement du code et de l'héritage est un plus élégant approche.
    • Le truc, c'est alors que j'ai utilisé (et observée) l'héritage depuis des années, je n'ai jamais vu beaucoup d'élégance à elle. La combinaison de l'état et de comportement? Assurez-vous. Virtuel expédition? Assurez-vous. Mais l'héritage? Il ne fonctionne vraiment quand vous avez un arbre de la hiérarchie, et puis après un an et demi de développement soudainement, vous remarquez que votre hiérarchie n'est plus en arbre et vous pouvez commencer. Cela dit, il est certainement vrai que beaucoup de langues modernes ont un mauvais support pour la composition - ce qui peut rendre la composition de beaucoup moins agiles que l'héritage dans certains cas (par exemple explicitement route des interfaces pour les enfants).
    • OK—je suis certainement admettre que, dans certains cas, la composition est préférable. Composition, cependant, tout comme l'héritage, peut être le parfait outil ou exactement le mauvais outil, en fonction de la situation. Mon point principal est la réponse n'est pas valide parce qu'il prévoit la composition toujours, et essaie ensuite au chausse-pied dans un exemple où il ne rentre pas. (Le modèle dans l'exemple serait mieux avec une combinaison à la fois de la composition et de l'héritage, comme je l'ai décrit dans mon premier commentaire.)
    • Cycle de vie des objets devrait être considéré lors du choix d'héritage. Manager "est un" Employé n'est pas bon si le Gestionnaire choisit un rôle différent et puis tout d'persistante des données de l'Employé doit être détruit puis recréé.

    InformationsquelleAutor aleemb
  4. 117

    Avec tous les indéniables avantages fournis par l'héritage, voici quelques-uns de ses inconvénients.

    Les inconvénients de l'Héritage:

    1. Vous ne pouvez pas changer la mise en œuvre hérité de super-classes au moment de l'exécution (évidemment parce que l'héritage est défini au moment de la compilation).
    2. Héritage expose une sous-classe de détails de sa classe parente de la mise en œuvre, c'est pourquoi il est souvent dit que l'héritage des pauses d'encapsulation (dans un sens que vous avez vraiment besoin de se concentrer sur les interfaces seulement pas mise en œuvre, de sorte que la réutilisation, par sous que le classement n'est pas toujours de préférence).
    3. Le couplage fournis par l'héritage fait de la mise en œuvre d'une sous-classe très lié à la mise en œuvre d'une classe super que tout changement dans le parent de la mise en œuvre sera la force de la classe de sous pour changer.
    4. Excessive de la réutilisation par des sous-classing peut faire de l'héritage de la pile de façon très profonde et très déroutant aussi.

    Sur l'autre main composition d'Objet est défini au moment de l'exécution à travers des objets d'acquérir des références à d'autres objets. Dans un tel cas, ces objets ne seront jamais en mesure d'atteindre les uns les autres protégés de données (pas de briser l'encapsulation) et sera forcé de se respecter les uns les autres de l'interface. Et dans ce cas également, la mise en œuvre des dépendances-être beaucoup moins que dans le cas de l'héritage.

    • C'est l'une des meilleures réponses, à mon avis je vais l'ajouter à cela que d'essayer de re-penser à vos problèmes en termes de composition, dans mon expérience, tend à aboutir à une plus petite, plus simple, plus autonome, plus des classes réutilisables, avec une plus claire, plus petit, plus ciblée de l'étendue de leur responsabilité. Souvent, cela signifie qu'il est moins nécessaire pour des choses comme l'injection de dépendance ou de se moquer (dans les tests) que de plus petits composants sont généralement en mesure de se tenir debout sur leur propre. Juste mon expérience. YMMV 🙂
    • Le dernier paragraphe de ce post vraiment cliqué pour moi. Je vous remercie.
    • Meilleure réponse, les mains vers le bas
    InformationsquelleAutor Galilyou
  5. 81

    Un autre, très pragmatique de la raison, de préférer la composition au cours de l'héritage a à voir avec votre modèle de domaine, et de la cartographie à une base de données relationnelle. C'est vraiment dur à la carte de l'héritage du modèle SQL (vous vous retrouvez avec toutes sortes de hacky solutions de contournement, comme la création de colonnes qui ne sont pas toujours utilisé, à l'aide de points de vue, etc). Certains ORMLs d'essayer de traiter avec cela, mais il obtient toujours compliqué rapidement. La Composition peut être facilement modélisé par une relation de clé étrangère entre les deux tables, mais l'héritage est beaucoup plus difficile.

    InformationsquelleAutor Tim Howland
  6. 74

    Tout en quelques mots, je suis d'accord avec "Préfèrent la composition au cours de l'héritage", très souvent, pour moi, ça sonne comme "préfèrent les pommes de terre dans du coca-cola". Il existe des lieux de l'héritage et des lieux pour la composition. Vous devez comprendre la différence, alors cette question va disparaître. Ce que cela signifie vraiment pour moi, c'est "si vous allez utiliser l'héritage - détrompez-vous, les chances sont que vous avez besoin de la composition".

    Vous devriez préférer les pommes de terre dans de coca-cola, lorsque vous voulez manger, et de coca-cola sur les pommes de terre quand vous voulez boire.

    La création d'une sous-classe doit signifier plus que juste un moyen pratique pour appeler les méthodes de la superclasse. Vous devriez utiliser l'héritage lors de la sous-classe "est-un" super classe à la fois structurellement et fonctionnellement, quand il peut être utilisé en tant que super-classe, et vous allez l'utiliser. Si ce n'est pas le cas - il n'est pas de l'héritage, mais quelque chose d'autre. La Composition est quand vos objets se compose de l'autre, ou a une certaine relation à eux.

    Donc, pour moi, c'est comme si quelqu'un ne sait pas si il a besoin de l'héritage ou de la composition, le vrai problème, c'est qu'il ne sait pas si il a envie de boire ou de manger. Pensez à votre problème de domaine de plus, de mieux le comprendre.

    • Le bon outil pour le bon travail. Un marteau peut-être mieux à pilonner les choses que d'une clé, mais cela ne signifie pas que l'on devrait voir une clé comme "inférieure du marteau". L'héritage peut être utile lorsque les choses qui sont ajoutés à la sous-classe sont nécessaires à l'objet de se comporter comme une super-classe de l'objet. Par exemple, considérons une classe de base InternalCombustionEngine avec une classe dérivée GasolineEngine. Ce dernier ajoute des choses comme les bougies d'allumage, qui est la classe de base manque, mais l'utilisation de la chose comme un InternalCombustionEngine sera la cause de la bougie d'allumage pour s'habituer.
    InformationsquelleAutor Pavel Feldman
  7. 55

    L'héritage est assez alléchant, surtout venant de la procédure-la terre et, souvent, elle ressemble étonnamment élégant. Je veux dire tout ce que je dois faire est d'ajouter ce un peu de fonctionnalité à une autre classe, non? Eh bien, l'un des problèmes est que

    l'héritage est probablement la pire forme de couplage, vous pouvez avoir

    Votre classe de base des sauts de l'encapsulation en exposant les détails de mise en œuvre de sous-classes dans le formulaire de membres protégés. Cela rend votre système rigide et fragile. Le plus tragique faille, cependant, est la nouvelle sous-classe apporte avec elle tout le bagage et l'opinion de la chaîne d'héritage.

    L'article, L'héritage est le Mal: L'Epic Fail de la DataAnnotationsModelBinder, promenades à travers un exemple en C#. Il montre l'utilisation de la transmission lors de la composition ont été utilisés et comment il pourrait être remaniée.

    • L'héritage n'est pas de bon ou de mauvais, c'est simplement un cas particulier de la Composition. Où, en effet, la sous-classe est mise en œuvre une fonctionnalité similaire à la super-classe. Si votre proposition de la sous-classe n'est pas re-mise en œuvre, mais simplement de via la fonctionnalité de la super-classe, puis vous avez utilisé l'Héritage de manière incorrecte. C'est le programmeur de l'erreur, pas une réflexion sur l'Héritage.
    InformationsquelleAutor Mike Valenty
  8. 40

    En Java ou en C#, un objet ne peut pas changer son type une fois qu'il a été instancié.

    Donc, si votre objet doit apparaître comme un objet différent ou de se comporter différemment selon l'état de l'objet ou les conditions, puis utilisez Composition: reportez-vous à État et Stratégie les Modèles de Conception.

    Si l'objet doivent être du même type, puis utilisez Héritage ou de mettre en œuvre des interfaces.

    • +1 j'ai trouvé de moins en moins que l'héritage fonctionne dans la plupart des situations. Je préfère de beaucoup partagé/interfaces héritées et de la composition des objets....ou est-il appelé l'agrégation? Ne me demandez pas, j'ai une EE degré!!
    • Je crois que c'est le scénario le plus courant où "la composition au cours de l'héritage" s'applique depuis deux pourrait être raccord en théorie. Par exemple, dans un système de marketing que vous pourriez avoir un de la notion de Client. Ensuite, un nouveau concept de PreferredClient apparaît plus tard. Devrait PreferredClient hériter Client? Un client privilégié "est un" client après tout, non? Eh bien, pas si vite... comme vous l'avez dit les objets ne peuvent pas changer de classe au moment de l'exécution. Comment voulez-vous le modèle de la client.makePreferred() opération? Peut-être que la réponse se trouve dans l'utilisation de la composition avec un manque de concept, d'une Account peut-être?
    • Plutôt que d'avoir différents type de Client classes, peut-être il y a juste un qui encapsule le concept d'un Account qui pourrait être un StandardAccount ou un PreferredAccount...
    InformationsquelleAutor Sung M. Kim
  9. 32

    Personnellement, j'ai appris à toujours préférer la composition au cours de l'héritage. Il n'est pas programmatique problème que vous pouvez résoudre avec l'héritage qui vous ne pouvez pas résoudre avec la composition; bien que vous pourriez avoir à utiliser des Interfaces(Java) ou de Protocoles(Obj-C) dans certains cas. Depuis C++ ne sait pas quelque chose, vous aurez à utiliser les classes de base abstraites, ce qui signifie que vous ne pouvez pas obtenir entièrement débarrasser de l'héritage en C++.

    Composition est souvent plus logique, elle offre une meilleure abstraction, une meilleure encapsulation, une meilleure réutilisation de code (en particulier dans les très grands projets) et est moins susceptible de casser quelque chose, à une distance juste parce que vous avez isolé le changement de n'importe où dans votre code. Il rend également plus facile à défendre la "Principe de Responsabilité Unique", qui est souvent désigné comme "Il ne devrait jamais y avoir plus d'une raison pour une classe de changement.", et cela signifie que chaque classe a un rôle spécifique et qu'elle ne devrait avoir des méthodes qui sont directement liées à son objet. Aussi avoir très peu profonde, arbre d'héritage, il est beaucoup plus facile de garder la vue d'ensemble, même lorsque votre projet commence à devenir vraiment grand. Beaucoup de gens pensent que l'héritage représente notre monde réel assez bien, mais ce n'est pas la vérité. Le monde réel utilise beaucoup plus la composition de l'héritage. À peu près chaque objet du monde réel, vous pouvez tenir dans votre main a été composées à l'autre, plus petit du monde réel des objets.

    Il y a des inconvénients de composition, même si. Si vous ignorez la succession purement et simplement et de se concentrer uniquement sur la composition, vous remarquerez que vous avez souvent à écrire quelques lignes de code qui n'étaient pas nécessaires si vous aviez utilisé l'héritage. Vous êtes également parfois obligés de se répéter et cela viole les Principe SEC (SEC = Don't Repeat Yourself). Aussi la composition nécessite souvent délégation, et une méthode est juste d'appeler une autre méthode d'un autre objet avec aucun autre code entourant cet appel. Ces "doubles appels de méthode" (ce qui peut facilement s'étendre à triple ou quadruple appels de méthode et de plus loin) ont beaucoup de moins bonnes performances que l'héritage, où vous avez simplement à hériter d'une méthode de votre parent. L'appel d'une méthode héritée peut être aussi rapide que d'appeler un non-hérité de l'une, ou il peut être un peu plus lent, mais elle est en général plus rapide que deux fois de suite les appels de méthode.

    Vous avez peut-être remarqué que la plupart des langages à objets ne permet pas l'héritage multiple. Bien qu'il existe quelques cas où l'héritage multiple peut vraiment vous acheter quelque chose, mais ce sont plutôt des exceptions que la règle. Chaque fois que vous exécutez dans une situation où vous pensez que "l'héritage multiple serait vraiment un truc cool pour résoudre ce problème", vous êtes habituellement à un point où vous devez re-penser l'héritage tout à fait, puisque même il faudrait peut-être quelques lignes de code, une solution basée sur la composition sera généralement beaucoup plus élégant, souple et évolutive..

    L'héritage est vraiment une fonctionnalité intéressante, mais je crains que ça a été galvaudé depuis quelques années. Les personnes traitées à l'héritage comme un marteau qui peut clou en tout, peu importe si c'était réellement un clou, une vis, ou peut-être quelque chose de complètement différent.

    InformationsquelleAutor Mecki
  10. 31

    N'ai pas trouvé une réponse satisfaisante ici, j'ai donc écrit une nouvelle.

    De comprendre pourquoi "préfèrent la composition au cours de l'héritage", il nous faut d'abord revenir l'hypothèse omis dans ce raccourci de langage.

    Il y a deux avantages de l'héritage: le sous-typage et sous-classement

    1. De sous-typage moyens conformes à un type (interface) la signature, c'est à dire un ensemble d'Api, et l'on peut remplacer une partie de la signature d'atteindre le sous-typage polymorphisme.

    2. Sous-classement moyen implicite de la réutilisation de la méthode mise en œuvre.

    Avec les deux avantages viennent avec deux fins différentes pour faire de l'héritage: sous-typage et orientée vers la réutilisation de code orienté.

    Si la réutilisation de code est la seule but, sous-classement peut donner plus que ce dont il a besoin, c'est à dire quelques méthodes publiques de la classe parent n'a pas beaucoup de sens pour l'enfant de la classe. Dans ce cas, au lieu de favoriser la composition au cours de l'héritage, la composition est exigé. C'est aussi là le "est-un" vs "a-un" notion vient de.

    De sorte que lorsque le sous-typage est résolu, c'est à dire l'utilisation de la nouvelle classe plus tard dans un polymorphe manière, ne nous sommes confrontés au problème du choix de l'héritage ou de la composition. C'est l'hypothèse qui obtient omis dans la version raccourcie de l'idiome en discussion.

    De sous-type est conforme à un type de signature, cela signifie que la composition a toujours pour exposer pas moins le montant de l'Api de type. Maintenant, le commerce offs de coup de pied dans:

    1. Héritage offre simple réutilisation de code si elle n'est pas remplacée, tandis que la composition a à re-coder toutes les API, même si c'est juste un simple travail de la délégation.

    2. Héritage fournit simples ouvrir la récursivité via l'interne site polymorphe this, c'est à dire invocation de méthode de remplacement (ou même type) dans un autre etat membre de la fonction, publique ou privée (bien que découragé). Ouvrir la récursivité peut être simulé par la composition, mais il exige un effort supplémentaire et ne peut pas toujours viable(?). Cette réponse à un double question parle de quelque chose de similaire.

    3. Héritage expose protégé membres. Cela rompt l'encapsulation de la classe parent, et si elle est utilisée par la sous-classe, une autre dépendance entre l'enfant et son parent est introduit.

    4. Composition a la conviennent de l'inversion de contrôle, et de sa dépendance peut être injecté de façon dynamique, comme c'est indiqué dans décorateur modèle et modèle de proxy.

    5. Composition a l'avantage de combinator-orienté de programmation, c'est à dire travailler d'une manière comme de l' diagramme composite.

    6. Composition suit immédiatement programmation d'une interface.

    7. Composition a l'avantage de facile l'héritage multiple.

    Ci-dessus, le commerce lié à l'esprit, nous nous sommes donc préfèrent la composition au cours de l'héritage. Pourtant, pour étroitement liées classes, c'est à dire quand implicite de la réutilisation de code vraiment apporter des avantages, ou le pouvoir magique d'ouvrir la récursivité est souhaitée, l'héritage doit être le choix.

    • Bonne réponse, mérite plus d' +1s.
    • Je n'ai pas trouvé une réponse satisfaisante ici, puis vous avez écrit un.
    InformationsquelleAutor lcn
  11. 21

    Mes règle générale: Avant l'utilisation de l'héritage, examiner si la composition a plus de sens.

    Raison: sous-classement signifie généralement plus de complexité et d'interdépendance, c'est à dire plus difficiles à modifier, maintenir et mettre à l'échelle sans faire de fautes.

    Beaucoup plus complète et concrète réponse de Tim Boudreau de Soleil:

    Problèmes communs à l'utilisation de l'héritage que je vois sont:

    • Innocent des actes peut avoir des résultats inattendus - L'exemple classique de ce qui est des appels à substituables les méthodes de la classe mère
      constructeur, avant de les sous-classes des champs d'instance ont été
      initialisé. Dans un monde parfait, personne ne serait jamais le faire. C'est
      pas un monde parfait.
    • Il propose des tentations perverses pour subclassers hypothèses à propos de l'ordre des appels de méthode et de ces - ces hypothèses ont tendance à ne pas
      stable si la super-classe peut évoluer au fil du temps. Voir aussi mon grille-pain
      et le pot de café analogie      .
    • Classes plus lourde - vous ne savent pas forcément ce qu'est le travail de votre super-classe est en train de faire dans son constructeur, ou de combien de mémoire il va
      pour l'utiliser. Donc, la construction d'un innocent serait-objet peut être léger
      être beaucoup plus cher que vous ne le pensez, et cela peut changer au fil du temps si
      la super-classe évolue
    • Il encourage une explosion de sous-classes. Classloading les coûts de temps, plus de classes coûts de la mémoire. Cela peut être un non-problème jusqu'à ce que vous êtes
      traiter avec une application sur l'échelle de NetBeans, mais là, nous avions de vrais
      les problèmes avec, par exemple, les menus de la lenteur, car le premier affichage
      d'un menu déclenché massive de chargement de classe. Nous avons résolu ce problème en déplaçant à
      plus de syntaxe déclarative et d'autres techniques, mais que le coût du temps de
      corriger ainsi.
    • , Il est plus difficile de changer les choses par la suite - si vous avez fait une classe publique, la permutation de la super-classe va briser les sous-classes -
      c'est un choix qui, une fois que vous avez fait le code public, vous êtes marié
      d'. Donc, si vous n'êtes pas altérer la fonctionnalité réelle de votre
      super-classe, vous obtenez beaucoup plus de liberté pour changer les choses par la suite si vous
      l'utilisation, plutôt que d'étendre la chose dont vous avez besoin. Prenez, par exemple,
      sous-classement Composite, ce qui est habituellement fait de mal; et si la sous-classe est
      public quelque part, vous n'obtenez jamais une occasion de revenir sur cette décision. Si
      il est consulté en tant que JComponent getThePanel() , vous pouvez toujours le faire (un indice:
      exposer des modèles pour les composants à l'intérieur de votre API).
    • Objet hiérarchies ne sont pas à l'échelle (ou à l'échelle plus tard est beaucoup plus difficile que de la planification à l'avance) - c'est la classique "de trop nombreuses couches"
      problème. Je vais aller dans cette ci-dessous, et comment le modèle peut AskTheOracle
      résoudre (même si ça peut choquer les puristes de la programmation orientée objet).

    ...

    De mon point de vue sur ce qu'il faut faire, si vous ne permettre l'héritage que vous pouvez
    prendre avec un grain de sel:

    • Exposez pas les champs, jamais, à l'exception des constantes
    • Méthodes doivent être abstraite, finale ou la finale
    • Appelez pas les méthodes de la classe mère constructeur

    ...

    tout cela s'applique moins à de petits projets que les grands, et moins
    pour les cours privés que publics

    InformationsquelleAutor Peter Tseng
  12. 18

    L'héritage est très puissant, mais vous ne pouvez pas le forcer (voir: la cercle ellipse problème). Si vous ne pouvez vraiment pas être complètement sûr d'un vrai "est-un" sous-type de relation, alors il est préférable d'aller avec la composition.

    InformationsquelleAutor yukondude
  13. 17

    Pourquoi préférer la composition au cours de l'héritage?

    Voir d'autres réponses.

    Quand devriez-vous choisir d'héritage sur la composition?

    Chaque fois que la phrase "un Bar" est un truc, et un Bar peut faire tout ce qu'un Foo peut le faire" de sens.

    La sagesse conventionnelle dit que si la phrase "un Bar" est un Foo" a du sens, alors c'est une bonne indication que le choix de l'héritage est approprié. Par exemple, un chien est un animal, donc d'avoir le Chien classe hérite de l'Animal est probablement une bonne conception.

    Malheureusement, ce simple "est-un" test n'est pas fiable. Le Cercle Ellipse problème est un excellent contre-exemple: même si un cercle est une ellipse, c'est une mauvaise idée d'avoir le Cercle classe hérite de l'Ellipse, car il y a des choses que ellipses peut faire, mais les cercles ne le peuvent pas. Par exemple, les points de suspension peuvent s'étirer, mais les cercles ne le peuvent pas. Ainsi, alors que vous pouvez avoir ellipse.stretch(), vous ne pouvez pas avoir circle.stretch().

    C'est pourquoi un meilleur test est "un Bar" est un Foo, et un Bar peut faire tout ce qu'un Foo peut faire". Cela signifie vraiment que Foo peut être utilisé polymorphically. Le "est-un" test n'est qu'une condition nécessaire pour polymorphe à utiliser, et signifie généralement que tous les getters de Foo a de sens que dans un Bar. Les autres "peut-faire-tout" test signifie que tous les poseurs de Foo également avoir du sens dans un Bar. Ce test supplémentaire échoue généralement quand une classe Bar "est-un" Foo, mais ajoute quelques contraintes, dans ce cas, vous ne devez pas utiliser l'héritage, parce que Toto n'a pas pu être utilisé polymorphically. En d'autres mots, l'héritage n'est pas sur les propriétés de partage, mais à propos de la fonctionnalité de partage de. Les classes dérivées doivent étendre la fonctionnalité des classes de base, et non de la restreindre.

    C'est l'équivalent de la Principe De Substitution De Liskov:

    Les fonctions qui utilisent des pointeurs ou des références à des classes de base doit être en mesure d'utiliser des objets des classes dérivées, sans le savoir,

    • Le cercle ellipse et le carré-rectangle scénarios sont de mauvais exemples. Les sous-classes sont toujours plus complexes que leur super-classe, de sorte que le problème est artificiel. Ce problème est résolu par l'inversion de la relation. Une ellipse dérive à partir d'un cercle et un rectangle de dérive à partir d'un carré. Il est extrêmement ridicule d'utiliser la composition de ces scénarios.
    • D'accord, mais en fait, mon post ne jamais plaide pour l'utilisation de la composition dans ce cas. J'ai seulement dit que le cercle ellipse problème, est un excellent exemple de pourquoi "est-un" n'est pas un bon test à lui seul de conclure que le Cercle doit dériver de l'Ellipse. Une fois que nous concluons qu'en réalité, le Cercle ne doit pas dériver de l'Ellipse en raison de la violation de LSP, puis les options possibles sont à inverser la relation, ou de l'utilisation de la composition, ou de l'utilisation du modèle de classes, ou de l'utilisation d'une conception plus complexe, impliquant des classes supplémentaires ou des fonctions d'assistance, etc... et la décision, évidemment, doit être prise au cas par cas.
    • Et si vous êtes curieux de savoir ce que je voudrais plaider pour le cas spécifique de Cercle-Ellipse: je serais partisan de ne pas mettre en œuvre le Cercle de la classe. Le problème avec l'inversion de la relation, c'est qu'il viole aussi le LSP: imaginez la fonction computeArea(Circle* c) { return pi * square(c->radius()); }. Il est cassé évidemment si elle est adoptée une Ellipse (ce qui n'rayon() même dire?). Une Ellipse est pas un Cercle, et en tant que tel ne devrait pas tirer de Cercle.
    • computeArea(Circle *c) { return pi * width * height / 4.0; } Maintenant il est générique.
    • Je suis en désaccord: vous vous rendez compte que cela signifie que la classe Cercle prévu l'existence de la classe dérivée de l'Ellipse, et donc fourni width() et height()? Que si maintenant, un utilisateur de la bibliothèque décide de créer une autre classe appelée "Oeuf"? Faut-il également dériver de "Cercle"? Bien sûr que non. Forme d'oeuf n'est pas un cercle et une ellipse n'est pas un cercle, donc personne ne doit dériver de Cercle, puisqu'elle brise la LSP. Les méthodes d'exécution de l'opération sur un Cercle* classe de faire des hypothèses fortes sur ce qu'est un cercle, et la rupture de ces hypothèses sera presque certainement conduire à des bugs.
    • Plus précisément, par l'ajout de l' (éventuellement virtuel) fonctions (largeur) et height() de Cercle, vous n'avez pas vraiment faire la classe générique. Vous venez de faire "un peu" plus générique, et le concept que votre classe représente aujourd'hui est en fait CircleOrEllipse, ce qui serait un meilleur nom pour cette classe. Mais encore une meilleure conception est d'avoir une classe de Forme avec une méthode virtuelle computeArea(), et deux sous-classes, appelé Cercle et de l'Ellipse. On a une méthode de rayon() tandis que l'autre dispose de deux méthodes (largeur) et height().
    • J'étais juste une blague 🙂 Mon seul os a été calage du problème dans le modèle de composition, mais vous informés de cela.
    • Ah, désolé, je ne suis pas le sarcasme 🙂

    InformationsquelleAutor Boris Dalstein
  14. 14

    Héritage crée une relation forte entre une sous-classe de super-classe, sous-classe doit être conscient de la super-classe es détails de mise en œuvre. La création de la super-classe est beaucoup plus difficile, quand vous avez à penser à la façon dont elle peut être prolongée. Vous avez de la classe de document invariants soigneusement, et de l'état de quelles autres méthodes méthodes substituables utiliser en interne.

    Héritage est parfois utile, si la hiérarchie représente vraiment un est-une-relation. Il se rapporte à Ouvert-Fermé Principe, qui stipule que les classes doivent être fermées pour la modification, mais ouvert à d'extension. De cette façon, vous pouvez avoir polymorphisme; avoir une méthode générique qui traite avec un super type et de ses méthodes, mais par l'intermédiaire de répartition dynamique de la méthode de la sous-classe est appelée. C'est flexible, et permet de créer des indirection, ce qui est essentiel dans le logiciel (à savoir moins sur les détails de l'implémentation).

    L'héritage est facilement galvaudé, cependant, et crée une complexité supplémentaire, avec beaucoup de dépendances entre les classes. Aussi la compréhension de ce qui se passe lors de l'exécution d'un programme est assez difficile en raison de couches et de sélection dynamique des appels de méthode.

    Je voudrais suggérer à l'aide de la composition en tant que par défaut. Il est plus modulaire, et offre l'avantage de la liaison tardive (vous pouvez changer le composant dynamiquement). Aussi, il est plus facile de tester les choses séparément. Et si vous avez besoin d'utiliser une méthode d'une classe, vous n'êtes pas forcé d'être d'une certaine forme (Principe de Substitution de Liskov).

    • Il est intéressant de noter que l'héritage n'est pas la seule façon d'atteindre le polymorphisme. Le Décorateur Modèle donne l'apparence de polymorphisme au travers de la composition.
    • Sous-type de polymorphisme est qu'une sorte de polymorphisme, une autre serait de polymorphisme paramétrique, vous n'avez pas besoin d'héritage pour que. Aussi le plus important: quand on parle de l'héritage, l'un des moyens d'héritage de classe; .j'.e. vous pouvez avoir des sous-type de polymorphisme par le fait d'avoir une interface commune à plusieurs classes, et vous n'obtenez pas les problèmes de l'héritage.
    • J'ai interprété votre commentaire Inheritance is sometimes useful... That way you can have polymorphism que de lier entre eux les concepts d'héritage et de polymorphisme (sous-typage supposé, vu le contexte). Mon commentaire était destiné à préciser ce qui vous préciser dans votre commentaire: que l'héritage n'est pas la seule façon de mettre en œuvre le polymorphisme, et, en fait, n'est pas nécessairement le facteur déterminant au moment de choisir entre la composition et l'héritage.
    InformationsquelleAutor egaga
  15. 13

    Supposons qu'un avion n'a que deux pièces: un moteur et les ailes.

    Ensuite, il y a deux façons de concevoir un avion de la classe. 

    Class Aircraft extends Engine{
  var wings;
}

    Maintenant votre avion peut commencer à avoir des ailes

    et de le modifier, de le rotary ailes de la mouche. C'est essentiellement

    un moteur avec des ailes. Mais que si je voulais changer

    le moteur à la volée ainsi?

    Soit la classe de base Engine expose un mutateur pour changer son

    propriétés, ou je la refonte Aircraft comme: 

    Class Aircraft {
  var wings;
  var engine;
}

    Maintenant, je peux remplacer mon moteur à la volée ainsi.

    • Votre post apporte un point que je n'avais pas envisagé avant--pour continuer votre une analogie avec la mécanique des objets avec plusieurs parties, sur quelque chose comme une arme à feu, il ya généralement une partie d'un numéro d'ordre, dont le numéro de série est réputée être celle de l'arme à feu dans son ensemble (pour une arme de poing, il serait généralement le cadre). On peut remplacer toutes les autres parties et ont toujours la même arme à feu, mais si le cadre des fissures et doit être remplacé, le résultat de l'assemblage d'un nouveau cadre avec toutes les autres parties de l'original canon serait un nouveau pistolet. Notez que...
    • ...le fait que plusieurs pièces d'une arme à feu peut avoir un numéro de série marqué sur eux ne signifie pas qu'une arme à feu peut avoir plusieurs identités. Seul le numéro de série sur le cadre identifie le pistolet; le numéro de série sur toute autre partie identifie le pistolet de ces pièces ont été fabriquées pour être assemblé avec, ce qui peut ne pas être l'arme à laquelle ils sont assemblés à un moment donné.
    InformationsquelleAutor dharm0us
  16. 13

    Vous avez besoin d'avoir un coup d'oeil à Le Principe De Substitution De Liskov de l'Oncle Bob est SOLIDE principes de conception de classe. 🙂

    InformationsquelleAutor nabeelfarid
  17. 10

    "Préfèrent la composition au cours de l'héritage" est un principe de conception, qui dit de ne pas abuser de l'héritage, quand il ne rentre pas.

    Si pas de monde réel lien de subordination existe entre les deux entités, ne pas utiliser l'héritage, mais au lieu d'utiliser la composition. La Composition représente "A UNE" relation".

    E. g. UNE voiture à Roues, carrosserie, moteur, etc. Mais si vous l'héritage ici, il devient de VOITURE EST UNE Roue qui est incorrect.

    Pour de plus amples explications, reportez-vous à préférez la composition au cours de l'héritage

    • Généralement la base du mal n'est pas simplement "la Voiture est une Roue", mais "la Voiture est quelque Chose d'à quatre roues, le volant, les fenêtres, les corps, les sièges ... tout ce que vous pouvez imaginer une bonne voiture devrait avoir". Habituellement, cela se termine avec un BaseCar qui est le Dieu tout puissant, Père de Voiture pour toutes les autres voitures. Tout fonctionne bien jusqu'à ce que vous avez besoin d'une voiture qui n'est pas typique, par exemple une voiture avec seulement trois roues ou un système automatisé de voiture sans volant. Alors seulement vous vous rendez compte que c'était peut-être pas grande idée de mettre en application toutes les fonctionnalités possibles sur toutes les voitures.
    • Pas une bonne réponse pour la même raison que celle sur les canines et les chiens n'est pas une bonne idée. La voiture problème peut être résolu plus Solidement avec la composition de trop. BMW met en œuvre voiture au lieu de BMW s'étend de la voiture.
    InformationsquelleAutor Ranganatha
  18. 7

    Quand vous voulez "copier"/Exposer la classe de base de l'API, vous utiliser l'héritage. Quand vous voulez seulement de la "copie" de la fonctionnalité, l'utilisation de la délégation.

    Un exemple: Vous voulez créer une Pile à partir d'une Liste. Pile a seulement pop, push et peek. Vous ne devriez pas utiliser l'héritage étant donné que vous ne voulez pas push_back, push_front, removeAt, et al.-type de fonctionnalité dans une Pile.

    InformationsquelleAutor Anzurio
  19. 6

    De côté de est a/a a considérations, on doit également considérer la "profondeur" de l'héritage de votre objet doit passer par. Rien au-delà de cinq ou six niveaux de l'héritage profonde peut provoquer inattendu casting et boxing/unboxing de problèmes, et dans ces cas, il pourrait être sage de composer votre objet à la place.

    InformationsquelleAutor Jon Limjap
  20. 6

    Ces deux façons de vivre ensemble est très bien et effectivement soutenir les uns les autres.

    Composition est juste à jouer c'est modulaire: vous créez une interface similaire à la classe parent, de créer de nouveaux objets et délégué appelle à elle. Si ces objets n'ont pas besoin de savoir les uns des autres, il est tout à fait sûr et facile à utiliser la composition. Il y a donc beaucoup de possibilités ici.

    Toutefois, si le parent de la classe pour une raison quelconque besoin d'accéder à des fonctions fournies par les "enfants de la classe" pour les inexpérimentés programmeur, il peut ressembler c'est un endroit idéal pour utiliser l'héritage. La classe parent peut simplement appeler son propre résumé "foo()" qui est remplacée par la sous-classe et puis, il peut donner de la valeur à la base abstraite.

    Il ressemble à une bonne idée, mais dans de nombreux cas, il est préférable de simplement donner la classe d'un objet qui implémente l'foo() (ou même de définir la valeur indiquée foo() manuellement) que pour hériter de la nouvelle classe à partir de certains de la classe de base qui nécessite de la fonction foo() doit être spécifié.

    Pourquoi?

    Parce que l'héritage est une mauvaise façon de déplacement de données.

    La composition a un réel avantage ici: la relation peut être inversée: la classe mère" ou "abstraite" travailleur peut agréger tout spécifique "des enfants" des objets de mise en œuvre de certaines interface + tout enfant peut être placé à l'intérieur de n'importe quel autre type de parent, qui l'accepte est de type. Et il peut y avoir un nombre quelconque d'objets, par exemple MergeSort ou QuickSort peut trier une liste d'objets de la mise en œuvre d'un résumé de Comparer l'interface. Ou pour le dire d'une autre façon: tout groupe d'objets qui mettent en œuvre des "foo()" et d'autres groupe d'objets, ce qui peut rendre l'utilisation des objets ayant "foo()" peuvent jouer ensemble.

    Je peux penser à trois vraies raisons de l'utilisation de l'héritage:

    1. Vous avez de nombreuses classes avec même interface et vous voulez gagner du temps à les écrire
    2. Vous devez utiliser la même Classe de Base pour chaque objet
    3. Vous avez besoin de modifier les variables privées, qui ne peut pas être public, en tout cas,

    Si elles sont vraies, alors il est probablement nécessaire pour utiliser l'héritage.

    Il n'y a rien de mal à utiliser la raison 1, c'est une très bonne chose d'avoir une solide interface sur vos objets. Cela peut être fait à l'aide de la composition ou de l'héritage, pas de problème - si cette interface est simple et ne change pas. Habituellement, l'héritage est très efficace ici.

    Si la raison est le numéro 2 ça devient un peu délicat. Avez-vous vraiment seulement besoin d'utiliser la même classe de base? En général, simplement en utilisant la même classe de base n'est pas assez bon, mais il peut être une exigence de votre cadre, une étude de conception qui ne peut pas être évitée.

    Cependant, si vous souhaitez utiliser les variables privées, le cas 3, alors vous pourriez être en difficulté. Si vous envisagez de variables globales dangereux, alors vous devriez considérer l'utilisation de l'héritage pour obtenir l'accès aux variables privées aussi dangereuse. Rappelez-vous, les variables globales ne sont pas si mal QUE ça - les bases de données sont essentiellement de grand ensemble de variables globales. Mais si vous pouvez le manipuler, il est tout à fait bien.

    InformationsquelleAutor Tero Tolonen
  21. 5

    Un moyen simple de donner un sens à cela serait que l'héritage doit être utilisé lorsque vous avez besoin d'un objet de votre classe à avoir le même interface comme son parent de la classe, de sorte qu'il peut ainsi être traité comme un objet de la classe parente (upcasting). En outre, les appels de fonction sur un objet de classe dérivée doit rester la même partout dans le code, mais la méthode à appeler serait déterminé au moment de l'exécution (c'est à dire le faible niveau mise en œuvre diffère, le haut niveau interface reste le même).

    Composition doit être utilisé lorsque vous n'avez pas besoin d'une nouvelle classe d'avoir la même interface, c'est à dire que vous souhaitez cacher certains aspects de la classe dans la mise en œuvre desquels l'utilisateur de la classe n'a pas besoin de connaître. Si la composition est plus dans la façon de soutenir encapsulation (c'est à dire en occultant la mise en œuvre), tandis que l'héritage est destiné à soutenir abstraction (par exemple en fournissant une représentation simplifiée de quelque chose, dans ce cas, le même interface pour une gamme de types avec différents éléments internes).

    • +1 pour la mention de l'interface. J'utilise cette approche pour masquer les classes existantes et faire ma nouvelle classe correctement unité vérifiable par se moquer de l'objet utilisé pour la composition. Cela exige que le propriétaire de l'objet nouveau pour passer le candidat à la classe parent à la place.
    InformationsquelleAutor Y.S
  22. 5

    Lorsque vous avez un est-un relation entre deux classes (exemple chien est un chien), vous allez pour l'héritage.

    D'autre part, si vous avez a-un ou certains adjectif de relation entre deux classes (étudiant a des cours) ou (professeur d'études des cours), vous avez choisi la composition.

    • Vous avez dit de l'héritage et de la succession. ne pas vous dire de l'héritage et la composition?
    • Non, vous ne le font pas. Vous pouvez tout aussi bien définir une canine de l'interface et que chaque chien de la mettre en œuvre et vous vous retrouverez avec plus SOLIDES de code.
    InformationsquelleAutor Amir Aslam
  23. 4

    De sous-typage est approprié et plus puissant, où le les invariants peuvent être énumérés, sinon utiliser la fonction de composition pour l'extensibilité.

    InformationsquelleAutor Shelby Moore III
  24. 4

    Je suis d'accord avec @Pavel, quand il dit, il y a des endroits pour la composition et il y a des endroits pour l'héritage.

    Je pense que l'héritage doit être utilisé si votre réponse est affirmative à l'une de ces questions.

    • Est votre classe une partie d'une structure qui bénéficie de polymorphisme ? Par exemple, si vous avez eu une Forme de classe, qui déclare une méthode draw(), puis nous avons clairement besoin d'Cercle et le Carré classes sous-classes de la Forme, de sorte que leur client classes dépendra de la Forme et pas sur des sous-classes.
    • Est-ce que votre classe besoin de ré-utiliser un haut niveau d'interactions défini dans une autre classe ? Le méthode de modèle modèle de conception serait impossible à mettre en œuvre sans héritage. Je crois que tous extensible cadres de l'utilisation de ce modèle.

    Toutefois, si votre intention est purement et simplement que de code de la réutilisation, puis la composition est probablement un meilleur choix de conception.

    InformationsquelleAutor Parag
  25. 3

    Une règle que j'ai entendu, c'est l'héritage doit être utilisé lorsque son "est-un" de la relation et de la composition lors de son une "a-un". Même avec que je sens que vous devriez toujours se pencher vers la composition car elle élimine beaucoup de complexité.

    InformationsquelleAutor
  26. 3

    L'héritage est un très puissant mécanisme de réutilisation de code. Mais il doit être utilisé correctement. Je dirais que l'héritage est utilisé correctement si la sous-classe est aussi un sous-type de la classe parent. Comme mentionné ci-dessus, le Principe de Substitution de Liskov est le point clé ici.

    Sous-classe n'est pas le même que le sous-type. Vous pouvez créer des sous-classes qui ne sont pas sous-types (et c'est quand vous devez utiliser la composition). Pour comprendre ce qu'est un sous-type est, permet de commencer à donner une explication de ce qu'un type est.

    Quand nous disons que le nombre 5 est de type entier, nous sommes en indiquant que 5 appartient à un ensemble de valeurs possibles (à titre d'exemple, voir les valeurs possibles pour les types primitifs de Java). Nous sommes également en déclarant qu'il est valide d'un ensemble de méthodes, je peux effectuer sur la valeur comme l'addition et la soustraction. Et enfin nous indiquant qu'il y a un ensemble de propriétés qui sont toujours satisfaits, par exemple, si j'ajoute les valeurs 3 et 5, je vais avoir 8 en conséquence.

    Pour donner un autre exemple, de réfléchir sur les types de données abstraite, Ensemble des entiers et Liste de nombres entiers, les valeurs qu'ils peuvent tenir sont limités à des entiers. Ils prennent en charge un ensemble de méthodes, telles que l'ajout(newValue) et la taille(). Et ils ont tous deux des propriétés différentes (classe invariant), des Ensembles de ne pas autoriser les doublons, tandis que la Liste n'autoriser les doublons (bien sûr il y a d'autres propriétés qu'ils ont à la fois satisfaire).

    Sous-type est également un type, qui a une relation d'un autre type, appelé type parent (ou supertype). Le sous-type doit satisfaire aux caractéristiques (valeurs, des méthodes et des propriétés) du type parent. La relation signifie que, dans un contexte où le supertype est attendue, il peut être substituables par un sous-type, sans affecter le comportement de l'exécution. Allons voir un peu de code pour illustrer ce que je dis. Supposons que j'écris une Liste d'entiers (dans une sorte de pseudo langue):

    class List {
  data = new Array();

  Integer size() {
    return data.length;
  }

  add(Integer anInteger) {
    data[data.length] = anInteger;
  }
}

    Alors, j'écris l'Ensemble des entiers comme une sous-classe de la Liste d'entiers:

    class Set, inheriting from: List {
  add(Integer anInteger) {
     if (data.notContains(anInteger)) {
       super.add(anInteger);
     }
  }
}

    Nos Ensemble des entiers de la classe est une sous-classe de la Liste d'Entiers, mais n'est pas un sous-type, du fait qu'il n'est pas satisfaisant à toutes les fonctionnalités de la Liste de classe. Les valeurs, et la signature de l'méthodes sont satisfaits, mais les propriétés ne sont pas. Le comportement de l'ajouter(Entier) méthode a été clairement changé, ne pas conserver les propriétés du type parent. Pense que du point de vue du client, de vos classes. Ils reçoivent un Ensemble d'entiers où une Liste d'entiers est prévu. Le client peut vouloir ajouter une valeur et la valeur ajoutée à la Liste, même si cette valeur existe déjà dans la Liste. Mais à son habitude d'obtenir ce comportement si la valeur existe. Une grande surprise pour elle!

    C'est un exemple classique d'une mauvaise utilisation de l'héritage. Utilisation de la composition dans ce cas.

    (un fragment de: utiliser l'héritage correctement).

    InformationsquelleAutor Enrique Molinari
  27. 3

    Pour répondre à cette question à partir d'un point de vue différent pour les nouveaux programmeurs:

    L'héritage est souvent enseigné dès le début, quand nous apprendre la programmation orientée objet, il est donc considéré comme une solution simple à un problème commun.

    J'ai trois classes que tous ont besoin de certaines fonctionnalités communes. Donc, si je
    écrire une classe de base et ont eux héritent tous de, puis ils vont
    tous ont cette fonctionnalité et je vais seulement mettre à jour en une fois
    place.

    Il a l'air génial, mais dans la pratique, presque jamais, jamais œuvres, pour une ou plusieurs raisons:

    • Nous découvrons qu'il y a d'autres fonctions que nous voulons que nos classes ont. Si la façon dont nous ajouter des fonctionnalités à des classes par héritage, nous devons décider de le faire, nous l'ajoutons à la classe de base existante, même si pas chaque classe qui en hérite les besoins de cette fonctionnalité? Pouvons-nous créer une autre classe de base? Mais ce que sur les classes déjà héritent l'un de l'autre classe de base?
    • Nous découvrons que pour seulement une des classes qui hérite de notre classe de base, nous voulons la classe de base à se comporter un peu différemment. Alors maintenant, nous allons revenir et de bricoler avec notre classe de base, peut-être que l'ajout de certaines méthodes virtuelles, ou encore pire, un peu de code qui dit, "Si je suis hérité de type A, faire cela, mais si j'ai hérité de type B, le faire." C'est mauvais pour beaucoup de raisons. L'une est que chaque fois que nous modifions la classe de base, nous sommes effectivement en changeant chaque classe héritée. Nous sommes donc vraiment changer de classe A, B, C, et D, parce que nous avons besoin d'un comportement légèrement différent dans la classe A. aussi prudent Que nous pensons que nous sommes, nous pourrions casser un de ces classes pour des raisons qui n'ont rien à voir avec les classes.
    • Nous sachions pourquoi nous avons décidé de faire toutes ces classes héritent les uns des autres, mais il pourrait ne pas (ne sera probablement pas) faire sens pour quelqu'un d'autre qui a pour effet de maintenir notre code. On pourrait les contraindre à un choix difficile - dois-je faire quelque chose de vraiment moche et brouillon pour faire le changement dont j'ai besoin (voir le point précédent point) ou dois-je simplement réécrire un tas de ce.

    En fin de compte, nous attacher à notre code dans certains difficile de noeuds et d'obtenir aucun avantage que ce soit, sauf que nous obtenons à-dire "Cool, j'ai appris à propos de l'héritage et maintenant je l'ai utilisé." Ce n'est pas destiné à être condescendant parce que nous l'avons tous fait. Mais nous l'avons tous fait parce que personne ne nous a dit de ne pas.

    Dès que quelqu'un a expliqué "favoriser la composition au cours de l'héritage" pour moi, je repense à chaque fois que j'ai essayé de partager les fonctionnalités entre les classes à l'aide de l'héritage et réalisé que la plupart du temps, il n'a pas vraiment bien.

    L'antidote est la Principe De Responsabilité Unique. Pensez à cela comme une contrainte. Ma classe doit faire une chose. Je doit être en mesure de donner ma classe un nom qui décrit en quelque sorte qu'une chose qu'il ne. (Il y a des exceptions à tout, mais de règles absolues sont parfois plus lorsque nous sommes à l'apprentissage.) Il s'ensuit que je ne peux pas écrire une classe de base appelée ObjectBaseThatContainsVariousFunctionsNeededByDifferentClasses. Quelle que soit la fonctionnalité distincte j'ai besoin doit être dans sa propre classe, et puis d'autres classes qui ont besoin de cette fonctionnalité dépend que de la classe, pas héritent de celui-ci.

    Au risque de simplifier à outrance, c'est la composition la composition de plusieurs classes à travailler ensemble. Et une fois que nous en forme que d'habitude, nous constatons qu'il est beaucoup plus souple, facile à maintenir, et testable que l'utilisation de l'héritage.

    • Que les classes ne pouvez pas utiliser plusieurs classes de base n'est pas un pauvre réflexion sur l'Héritage, mais plutôt un pauvre réflexion sur une langue en particulier, du manque de capacité.
    • Dans le temps depuis la rédaction de cette réponse, j'ai lu ce post à partir de "Oncle Bob", qui traite de ce manque de capacité. Je n'ai jamais utilisé un langage qui permet l'héritage multiple. Mais en regardant en arrière, la question est taggés avec "langue agnostique" et ma réponse n'assume C#. J'ai besoin d'élargir mes horizons.
    InformationsquelleAutor Scott Hannen
  28. 2

    Composition v/s l'Héritage est un vaste sujet. Il n'y a pas de véritable réponse pour ce qui est meilleur, car je pense que tout dépend de la conception du système.

    Généralement le type de relation entre l'objet fournir de meilleures informations pour choisir l'un d'eux.

    Si la relation de type "EST-UN" rapport puis l'Héritage est la meilleure approche.
    autrement relation de type "EST-UN" de la relation, puis la composition à une meilleure approche.

    Son totalement dépendent de l'entité-relation.

    InformationsquelleAutor Shami Qureshi
  29. 1

    Que beaucoup de personnes ont dit, je vais d'abord commencer avec le check - s'il existe un "est-un" de la relation. S'il existe, j'ai l'habitude de vérifier les points suivants:

    Si la classe de base peut être instancié. Qui est de savoir si la classe de base peut être abstrait. Si elle peut être abstrait d'habitude, je préfère la composition

    E. g 1. Comptable est un Employé. Mais je vais pas utiliser l'héritage, car un Employé de l'objet peut être instancié.

    E. g 2. Livre est un SellingItem. Un SellingItem ne peut pas être instanciée - c'est un concept abstrait. Donc, je vais utiliser inheritacne. Le SellingItem est un classe de base abstraite (ou l'interface en C#)

    Que pensez-vous de cette approche?

    Aussi, je soutiens @anon réponse dans Pourquoi utiliser l'héritage à tous?

    La raison principale de l'utilisation de l'héritage n'est pas aussi une forme de composition est - il si vous pouvez obtenir polymorphes comportement. Si vous n'avez pas besoin de polymorphisme, vous ne devriez probablement pas être en utilisant l'héritage.

    @MatthieuM. dit dans https://softwareengineering.stackexchange.com/questions/12439/code-smell-inheritance-abuse/12448#comment303759_12448

    La question de l'héritage, c'est qu'il peut être utilisé pour les deux orthogonaux fins:

    interface (polymorphisme)

    de mise en œuvre (pour la réutilisation de code)

    RÉFÉRENCE

    1. La classe est meilleur?
    2. L'héritage vs Agrégation
    • Je ne suis pas sûr pourquoi, la classe de base abstraite?' figures dans la discussion.. le LSP: avec tous les fonctions qui opèrent sur des Chiens de travail si Caniche objets sont passés dans l' ? Si oui, alors le Caniche est peut être substitué pour le Chien et peut donc hériter de Chien.
    • Merci. Je vais certainement regarder dans les LSP. Mais avant cela, pouvez-vous veuillez donner une "exemple où l'héritage est approprié dans lequel la classe de base ne peut pas être abstraite". Ce que je pense, l'héritage est applicable que si la classe de base abstraite. Si la classe de base doivent être instancié séparément, ne vont pas pour l'héritage. Qui est, même si l'expert-Comptable est un Employé, ne pas utiliser l'héritage.
    • été la lecture de la WCF ces derniers temps. Un exemple dans le .net framework est SynchronizationContext (base + peut être instancié) qui les files d'attente de travail sur un pool de threads thread. Les dérivations d'inclure WinFormsSyncContext (file d'attente sur le Thread de l'INTERFACE utilisateur) et DispatcherSyncContext (file d'attente sur le Répartiteur WPF)
    • Merci. Cependant, il serait plus utile si vous pouvez fournir un scénario basé sur la Banque de domaine, domaine des ressources humaines, le commerce de Détail de domaine ou tout autre domaine populaire.
    • Désolé. Je ne suis pas familier avec ces domaines.. un Autre exemple, si le précédent était trop obtus est la classe de Contrôle dans Winforms/WPF. La base générique de contrôle peut être instancié. Les dérivations d'inclure des zones de liste, des zones de texte, etc. Maintenant que j'y pense, le Décorateur est un bon exemple à mon humble avis et utile aussi. Le décorateur découle de la non-objet abstrait qu'il veut enveloppement à décorer.
    InformationsquelleAutor Lijo
  30. 1

    Même si la Composition est préféré, je tiens à souligner les pros de Héritage et les inconvénients de Composition.

    Pros de l'Héritage:

    1. Il établit une logique "EST UN" relation. Si Voiture et Camion sont deux types de Véhicule ( classe de base), les enfants de la classe EST UN de la classe de base.

      c'est à dire

      Voiture est un Véhicule

      Camion est un Véhicule

    2. Avec l'héritage, vous pouvez définir/modifier/extension d'une capacité de

      1. De la classe de Base ne fournit aucune mise en œuvre et de la sous-classe a remplacer l'ensemble de la méthode (résumé) => Vous pouvez mettre en œuvre un contrat
      2. Classe de Base fournit par défaut de mise en œuvre et de la sous-classe peut changer le comportement => Vous pouvez re-définir contrat
      3. Sous-classe ajoute l'extension de la classe de base de la mise en œuvre par un appel à super.methodName() comme première instruction => Vous pouvez prolonger un contrat de
      4. De la classe de Base définit la structure de l'algorithme et de la sous-classe de remplacer une partie de l'algorithme => Vous pouvez mettre en œuvre Template_method sans changement de classe de base squelette

    Les inconvénients de la Composition:

    1. En héritage, sous-classe peut directement invoquer la méthode de classe de base, même si ce n'est pas la mise en œuvre de méthode de classe de base en raison de EST UN relation. Si vous utilisez la composition, vous devez ajouter des méthodes dans la classe de conteneur pour exposer le contenu de classe de l'API

    par exemple, Si Voiture contient Véhicule et si vous avez du prix de la Voiture, qui a été défini dans Véhicule, votre code sera comme ceci

    class Vehicle{
     protected double getPrice(){
          //return price
     }
} 

class Car{
     Vehicle vehicle;
     protected double getPrice(){
          return vehicle.getPrice();
     }
}
    • Je pense qu'il ne répond pas à la question
    • Vous pouvez avoir re-regarder OP question. J'ai répondu : Quels compromis sont là pour chaque approche?
    • Comme vous l'avez mentionné, vous parler que des "pros de l'Héritage et les inconvénients de la Composition", et non pas les avantages et les inconvénients de CHAQUE approche ou le cas où vous devez utiliser l'un sur l'autre
    • les avantages et les inconvénients offre commerce-off depuis pros de l'héritage est un des inconvénients de la composition et les inconvénients de composition, avantages de l'héritage.
    InformationsquelleAutor Ravindra babu
  31. 0

    Que voulez-vous la force de vous-même (ou un autre programmeur) à respecter et à quand voulez-vous permettre à vous-même (ou un autre programmeur) plus de liberté. Il a été soutenu que l'héritage est utile lorsque vous souhaitez forcer quelqu'un à une manière de gérer ou de résoudre un problème particulier, de sorte qu'ils ne peuvent pas la tête dans la mauvaise direction.

    Is-a et Has-a est une règle générale.

    InformationsquelleAutor
  32. 0

    Je ne vois pas mentionné le diamant problème, qui peut survenir avec l'héritage.

    En un coup d'œil, si les classes B et C héritent d'Un et de deux remplacer la méthode X, et une quatrième classe D hérite de B et C, et de ne pas remplacer X, dont la mise en œuvre de X D est supposé utiliser?

    Wikipédia offre un bel aperçu du sujet traité dans cette question.

    • D hérite de B et C non A. Si oui, alors il utilisera la mise en œuvre de X qui est dans la classe A.
    • merci, j'ai édité le texte. Par la manière, un tel scénario ne peut pas se produire dans des langues qui ne permettent pas l'héritage de classe multiple, ai-je le droit ?
    • oui vous avez raison.. et je n'ai jamais travaillé avec l'un, qui permet l'héritage multiple (comme par exemple dans le diamant problème)..
    InformationsquelleAutor Veverke
  33. -2

    Cette règle est un non-sens complet. Pourquoi?

    La raison en est que, dans tous les cas, il est possible de dire si l'utilisation de la composition ou de l'héritage.
    Ceci est déterminé par la réponse à une question: "EST quelque chose d'Une autre chose" ou "A
    quelque chose d'Une autre chose".

    Vous ne pouvez pas "préfèrent" faire quelque chose pour quelque chose d'autre ou quelque chose d'autre. La logique stricte les règles s'appliquent.

    Aussi il n'y a pas "inventé exemples" parce que, dans chaque situation, une réponse à cette question ne peut être donnée.

    Si vous ne pouvez pas répondre à cette question il y a quelque chose de mal.
    Cela comprend
    le chevauchement des responsabilités de classess qui sont habituellement le résultat de de la mauvaise utilisation des interfaces, moins souvent par les réécrire le même code dans différents classess.

    Pour éviter ces situations, je vous le recommande d'utiliser les bons noms de classes , que pleinement à leurs responsabilités.

    • Votre point est une bonne idée, mais je pense qu'il devrait être formulé de manière un peu mieux; aussi, il y a est certains cas limites (vous en suggère pas du tout). Le point clé est que dans la plupart des cas, la décision est en fait très simple et ne doit pas être considéré comme un appel de jugement. La vraie question en se demandant si un truc devrait est un Bar ou contient un, sera de savoir s'il sera nécessaire d'avoir le code opérer sur le Foo dans un Bar *tout en conservant son identité en tant que Bar. Si pas, il suffit d'encapsuler un Foo et de l'exposer en tant que membre.
    • Il n'ya pas de cas limites. Tous les cas peuvent être résolus par des facteurs qui ne sont pas évidentes au premier abord. La question nécessite une analyse profonde, sinon arbitraire de la décision de causer des problèmes conduisant à un mauvais code.
    • Et seulement la sémantique peut le déterminer. Si vous êtes dans la situation quand vous avez besoin d'un code pour fonctionner sur les Foo dans un Bar tout en conservant son identité en tant que Barre d' - vous ne devriez pas prendre de décision sur ce point. Vous, en tant que concepteur de la classe de l'API doit savoir si l'utilisation de délégués ou exposer que membre.
    • Un modèle orienté-objet de l'univers doit être considérée comme un outil qui est souvent utile pour faciliter la résolution de nombreux problèmes du monde réel. Pas tous les problèmes du monde réel sont un bon ajustement pour un modèle orienté-objet, cependant. Parfois, même si l'héritage n'est pas un ajustement parfait pour un modèle orienté-objet, il peut permettre à un code existant pour être utilisé, sans modification, dans les cas qui nécessiteraient plus de reprise. Une telle utilisation peut subir quelques "dette technique", mais si le programme est prévu pour être obsolètes avant cela pose un problème, par exemple l'obsolescence aurait essentiellement pour effet d'évacuer toute cette dette.
    • Tous les problèmes du monde réel peut être résolu à l'aide d'un modèle orienté objet, parce que le tout s'intègre dans une définition de l'objet. L'héritage est le seul ajustement pour un modèle orienté-objet. Je connais des cas où la recherche de personnes réfugiées dans les interfaces, de traits ou de l'héritage multiple, car ils sont tout simplement pas capable de trouver le bon héritage. C'est leur code qui représente la dette technique, ce qui signifie, en réalité, de la négligence et de l'ignorance. Tout en algorithmique exactitude vient d'processus itératif d'essais et d'erreurs - POO n'autorise pas toutes les erreurs qui instantanément prendre leur péage. . . .
    • . . . Et c'est une raison pourquoi il y a beaucoup de mauvais code, beaucoup de mauvaises pratiques sont enseignées (comme SOLIDE et AGILE). Cette approches sont présentées comme une solution à la programmation des douleurs. Mais il n'y a pas de solutions, pas de règle d'or. Les douleurs vont durer éternellement, parce que Dieu maudit la terre, de faire ce genre de choses que ces "technigques" ont "offrir" ajouter à ces douleurs de plus en plus, de ne pas mentionner que moins de bonnes choses en sortir. Le logiciel à ce jours, comme tout le monde peut voir, c'est peu profonde, inintéressant, superficiel et pas cher. Sans intérêt et des uncolorfull.
    • Dans le monde réel, les systèmes sont à remplacer régulièrement. Des systèmes bien conçus de la place pour au moins une couche de "bidouille" changements à mettre en œuvre de manière fiable si aucun autre changement n'est jamais obligatoire. Si un nouveau système sera de passage à la ligne dans un mois et l'ancien système n'aura pas d'utilité, après l'heure, mais les gens ont besoin d'ajouter une nouvelle fonction à l'ancien système dès que possible, une bidouille qui peut être mis en œuvre de manière fiable dans 48 heures peut être préférable à un mieux-ensemble de solutions techniques qui permettraient de tenir une semaine. Si il s'avère que le nouveau système n'entre jamais en ligne, la bidouille peut causer de la douleur plus tard, mais...
    • ...si le nouveau système est installé sur le calendrier, l'effort supplémentaire requis pour une solution propre peut être essentiellement perdu.
    • Ils sont remplacés parce qu'ils ne sont pas parfaits et qu'ils ne sont pas parfaits parce qu'ils sont créés avec de l'argent dans l'esprit et non pas de leurs utilisateurs. C'est la réponse ultime pourquoi ils échouent. Cela implique des deux côtés: les producteurs qui veulent réduire les coûts et le consommateur qui ne veut pas consacrer suffisamment de temps pour analyser ses besoins réels afin de maximiser ses profits en participant à d'autres activités.
    • "Tous les problèmes du monde réel peut être résolu à l'aide d'un modèle orienté objet, parce que le tout s'intègre dans une définition de l'objet." Tous les problèmes du monde réel peut également être résolu par une Machine de Turing, parce que tout s'inscrit dans une définition de la Machine de Turing. Qui n'est pas une bonne idée.
    • leader avec "Cette règle est un non-sens complet" est un peu obtus, essayez de faire les points de la déclaration forte.
    • Ce n'est pas une règle, c'est un principe. Si c'est une règle alors on pourrait logiquement l'interpréter comme "le fait de ne Jamais, jamais hériter. Composer à la place." Moins programmeur expérimenté besoins de conseils. Ils ne vont pas intuitivement va savoir ce qui est mieux, et ils ont tendance à se pencher vers l'héritage parce que le matériel d'apprentissage à mettre en valeur. Et programmeurs expérimentés de faire de mauvais choix, donc c'est bon pour nous tous.
    • En effet, la question de l'OP est plutôt inutile. C'est comme demander: "quel est le meilleur, en train ou en bateau?". Si vous êtes sur une île, sans ponts, le bateau est mieux. Si vous êtes loin de la côte et de la destination est connecté à vous par terre, le train, c'est mieux. Dans certaines situations, l'héritage implique moins de travail, dans d'autres situations, la composition implique moins de travail.

    InformationsquelleAutor spectre