Quel est le but de l'héritage en Python?

L'héritage en Python est tout au sujet de la réutilisation de code. Factoriser les fonctionnalités communes dans une classe de base, et mettre en œuvre différentes fonctionnalités dans les classes dérivées.

L'héritage en Python est plus pratique qu'autre chose. Je trouve qu'il est mieux utilisé pour fournir une classe avec "comportement par défaut."

en effet, il y a une communauté significative de devs Python qui s'opposent à l'usage de l'héritage. Quoi que tu fasses, n'en fais pas trop. Avoir une hiérarchie de classe trop compliquée est une façon sûre d'obtenir étiqueté un "programmeur Java", et vous ne pouvez tout simplement pas avoir cela. :- )

je pense que le but de l'héritage en Python n'est pas de faire compiler le code, c'est pour la vraie raison de l'héritage qui étend la classe dans une autre classe enfant, et pour outrepasser la logique dans la classe de base. Cependant, le fait de taper duck en Python rend le concept "interface" inutile, car vous pouvez simplement vérifier si la méthode existe avant invokation sans avoir besoin d'utiliser une interface pour limiter la structure de la classe.

je pense qu'il est très difficile de donner une réponse concrète et significative avec de tels exemples abstraits...

pour simplifier, il existe deux types d'héritage: l'interface et la mise en œuvre. Si vous devez hériter de l'implémentation, alors python n'est pas si différent que des langages OO statiquement typés comme C++.

héritage d'interface est là où il ya une grande différence, avec des conséquences fondamentales pour la conception de votre logiciel en de mon expérience. Les langages comme Python ne vous forcent pas à utiliser l'héritage dans ce cas, et éviter l'héritage est un bon point dans la plupart des cas, parce qu'il est très difficile de fixer un mauvais choix de conception là-bas plus tard. C'est un point bien connu soulevé dans n'importe quel bon livre.

il y a des cas où l'utilisation de l'héritage pour les interfaces est conseillée en Python, par exemple pour les plug-ins, etc... Pour ces cas, Python 2.5 et inférieur manque d'une approche" intégrée " élégante, et plusieurs grands frameworks ont conçu leurs propres solutions (zope, trac, twister). Python 2.6 et au-dessus a classes ABC pour résoudre ce .

En C++/Java/etc, le polymorphisme est causée par l'héritage. Abandonnez cette croyance malencontreuse, et des langues dynamiques s'ouvrent à vous.

Essentiellement, en Python il n'y a pas d'interface tellement que "la compréhension que certaines méthodes sont remboursables". Assez attrayante et universitaire de sondage, non? Cela signifie que parce que vous appelez " parler "vous attendez clairement que l'objet devrait avoir une méthode" parler". Simple, hein? C'est très Liskov-ian en ce que les utilisateurs d'une classe définir son interface, un bon concept de conception qui vous mène à une meilleure santé TDD.

donc ce qui reste est, comme un autre poster poliment réussi à éviter de dire, un truc de partage de code. Vous pourriez écrire le même comportement dans chaque classe "enfant", mais ce serait redondant. Plus facile d'hériter ou de mélanger-dans la fonctionnalité qui est invariant à travers la hiérarchie de l'héritage. Plus petit, le code plus sec est meilleur en général.

ce n'est pas un héritage que de taper du canard rend inutile, ce sont des interfaces-comme celle que vous avez choisie pour créer une classe animale abstraite.

si vous aviez utilisé une classe animale qui introduisait un comportement réel pour ses descendants, alors des classes de chiens et de chats qui introduisaient un comportement supplémentaire, il y aurait une raison pour les deux classes. C'est seulement dans le cas de la classe ancêtre ne fournissant aucun code réel aux classes descendantes que votre l'argument est correct.

parce que Python peut connaître directement les capacités de n'importe quel objet, et parce que ces capacités sont mutables au-delà de la définition de classe, l'idée d'utiliser une interface abstraite pure pour "dire" au programme quelles méthodes peuvent être appelées est quelque peu inutile. Mais ce n'est pas le seul, ni même le principal, point d'héritage.

vous pouvez contourner l'héritage en Python et à peu près n'importe quelle autre langue. Il s'agit de réutiliser le code et de le simplifier.

c'est juste un truc sémantique, mais après avoir construit vos classes et vos classes de base, vous n'avez même pas besoin de savoir ce qui est possible avec votre objet pour voir si vous pouvez le faire.

dites que vous avez d qui est un chien qui sous-classe Animal.

command = raw_input("What do you want the dog to do?")
if command in dir(d): getattr(d,command)()

si ce que l'Utilisateur a saisi est disponible, le code exécutera la méthode appropriée.

en utilisant ceci vous pouvez créer n'importe quelle combinaison de monstre Hybride mammifère/Reptile/oiseau que vous voulez, et maintenant vous pouvez le faire dire ' Bark!"tout en volant et sortir sa langue fourchue et il le manipulera correctement! Avoir du plaisir avec elle!

Je ne vois pas l'intérêt d'hériter.

chaque fois que j'ai utilisé l'héritage dans des systèmes réels, j'ai été grillé parce qu'il conduisait à un enchevêtrement de dépendances, ou j'ai tout simplement réalisé à temps que je serais bien mieux sans. Maintenant, j'évite autant que possible. J'ai tout simplement jamais l'utiliser.

class Repeat:
    "Send a message more than once"
    def __init__(repeat, times, do):
        repeat.times = times
        repeat.do = do

    def __call__(repeat):
        for i in xrange(repeat.times):
             repeat.do()

class Speak:
    def __init__(speak, animal):
        """
        Check that the animal can speak.

        If not we can do something about it (e.g. ignore it).
        """
        speak.__call__ = animal.speak

    def twice(speak):
        Repeat(2, speak)()

class Dog:
     def speak(dog):
         print "Woof"

class Cat:
     def speak(cat):
         print "Meow"

>>> felix = Cat()
>>> Speak(felix)()
Meow

>>> fido = Dog()
>>> speak = Speak(fido)
>>> speak()
Woof

>>> speak.twice()
Woof

>>> speak_twice = Repeat(2, Speak(felix))
>>> speak_twice()
Meow
Meow

James Gosling s'est fait poser une question à la conférence de presse: "si tu pouvais revenir en arrière et faire Java différemment, que voulez-vous quitter?". Sa réponse fut "Classes", pour lesquelles il y eut des rires. Cependant, il était sérieux et a expliqué que vraiment, ce n'était pas les classes qui étaient le problème mais l'héritage.

je l'ai vue comme une dépendance à la drogue - il vous donne une solution rapide qui sent bon, mais à la fin, il mess. Je veux dire par là que c'est un moyen pratique de réutiliser du code, mais cela force un couplage malsain entre la classe de l'enfant et la classe du parent. Des modifications à la le parent peut briser l'enfant. L'enfant dépend du parent pour certaines fonctionnalités et ne peut pas les modifier. Par conséquent, la fonctionnalité fournie par l'enfant est également lié à la mère - vous ne pouvez avoir les deux.

mieux est de fournir une classe de face client unique pour une interface qui implémente l'interface, en utilisant la fonctionnalité d'autres objets qui sont composés au moment de la construction. Ceci via des interfaces correctement conçues, tous les couplages peut être éliminé et nous fournissons une API hautement composable (ce n'est pas nouveau - la plupart des programmeurs le font déjà, mais pas assez). Notez que la classe d'implémentation ne doit pas simplement exposer la fonctionnalité, sinon le client doit juste utiliser les classes composées directement - il doit faire quelque chose de nouveau en combinant cette fonctionnalité.

il y a l'argument du camp de l'héritage que la mise en œuvre pure délégation souffre parce qu'ils exigent beaucoup de méthodes de "colle" qui ne font que transmettre des valeurs à travers une "chaîne" de délégation. Toutefois, il s'agit tout simplement de réinventer une conception de type héritage en utilisant la délégation. Les programmeurs qui ont trop d'années d'exposition aux conceptions basées sur l'héritage sont particulièrement vulnérables à tomber dans ce piège, car, sans s'en rendre compte, ils penseront à la façon dont ils mettraient en œuvre quelque chose en utilisant l'héritage et puis convertir cela en délégation.

séparation correcte des préoccupations comme le le code ci-dessus ne nécessite pas de méthodes de colle, car chaque étape est en fait ajouter de la valeur , de sorte qu'ils ne sont pas vraiment des méthodes de "colle" du tout (si elles ne ajoutent pas de valeur, la conception est défectueuse).

il se résume à ceci:

• pour le code réutilisable, chaque classe ne doit faire qu'une chose (et le font bien).

• L'héritage crée des classes qui font plus d'une chose, parce qu'ils sont mélangé avec les cours des parents.

• par conséquent, l'utilisation de l'héritage rend les classes qui sont difficiles à réutiliser.

un Autre petit point, c'est que l'op s 3'rd exemple, vous ne pouvez pas appeler isinstance(). Par exemple, en passant votre exemple 3'rd à un autre objet qui prend et "Animal" type Un appel parle dessus. Si vous le faites, il ne vous aura à vérifier pour chien type, type de chat, et ainsi de suite. Pas sûr si la vérification d'instance est vraiment "Pythonic", à cause de la liaison tardive. Mais alors vous devez mettre en œuvre une certaine façon que le AnimalControl n'essaie pas de jeter les types Cheeseburger dans le camion, parce que Cheeseburgers ne parlez pas.

class AnimalControl(object):
    def __init__(self):
        self._animalsInTruck=[]

    def catachAnimal(self,animal):
        if isinstance(animal,Animal):
            animal.speak()  #It's upset so it speak's/maybe it should be makesNoise
            if not self._animalsInTruck.count <=10:
                self._animalsInTruck.append(animal) #It's then put in the truck.
            else:
                #make note of location, catch you later...
        else:
            return animal #It's not an Animal() type / maybe return False/0/"message"

en Python sont essentiellement des façons de regrouper un ensemble de fonctions et de données.. Ils sont différents des classes en C++ et autres..

j'ai surtout vu l'héritage utilisé pour surpasser les méthodes de la super-classe. Par exemple, peut-être une utilisation plus Python'ish de l'héritage serait..

from world.animals import Dog

class Cat(Dog):
    def speak(self):
        print "meow"

bien sûr, les chats ne sont pas un type de chien, mais j'ai ce (tiers) Dog classe qui fonctionne parfaitement, sauf la méthode speak que je veux outrepasser - cela évite de re-implémenter toute la classe, juste pour qu'elle miaule. Encore une fois , alors que Cat n'est pas un type de Dog , mais un chat hérite beaucoup d'attributs..

un bien meilleur exemple (pratique) d'annulation d'une méthode ou d'un attribut est la façon dont vous changez l'agent utilisateur pour urllib. Vous essentiellement sous-classe urllib.FancyURLopener et de changer l'attribut de version ( de la documentation ):

import urllib

class AppURLopener(urllib.FancyURLopener):
    version = "App/1.7"

urllib._urlopener = AppURLopener()

D'autres exceptions sont utilisées pour les Exceptions, lorsque l'héritage est utilisé d'une manière plus "appropriée":

class AnimalError(Exception):
    pass

class AnimalBrokenLegError(AnimalError):
    pass

class AnimalSickError(AnimalError):
    pass

..vous pouvez alors attraper AnimalError pour attraper toutes les exceptions qui héritent de lui, ou un spécifique comme AnimalBrokenLegError