В чем смысл наследования в Python?

наследование в Python - это повторное использование кода. Разложим общую функциональность в базовый класс и реализовать различные функции в производных классах.

наследование в Python является более удобным, чем что-либо еще. Я считаю, что лучше всего использовать для предоставления класса с "поведением по умолчанию."

действительно, существует значительное сообщество разработчиков Python, которые возражают против использования наследования вообще. Что бы вы ни делали, не переусердствуйте. Наличие слишком сложной иерархии классов-это верный способ получить ярлык "Java-программиста", и вы просто не можете этого сделать. : -)

Я думаю, что точка наследования в Python-это не компиляция кода, а реальная причина наследования, которая расширяет класс в другой дочерний класс и переопределяет логику в базовом классе. Однако утка, набранная в Python, делает концепцию" интерфейса " бесполезной, потому что вы можете просто проверить, существует ли метод перед вызовом без необходимости использовать интерфейс для ограничения структуры класса.

Я думаю, что очень трудно дать осмысленный, конкретный ответ с такими абстрактными примерами...

для упрощения существует два типа наследования: интерфейс и реализация. Если вам нужно наследовать реализацию, то python не так уж отличается от статически типизированных языков OO, таких как C++.

наследование интерфейса, где есть большая разница, с фундаментальными последствиями для дизайна вашего программного обеспечения в моем опыте. Языки как Python не заставляет вас использовать наследование в этом случае, и избежать наследования является хорошим моментом в большинстве случаев, потому что очень трудно исправить неправильный выбор дизайна там позже. Это хорошо известный момент, поднятый в любой хорошей книге ООП.

есть случаи, когда использование наследования для интерфейсов целесообразно в Python, например для плагинов и т. д... Для этих случаев Python 2.5 и ниже не хватает" встроенного " элегантного подхода, и несколько больших фреймворков разработали свои собственные решения (zope, trac, twister). Python 2.6 и выше ABC классы, чтобы решить эту.

в C++/Java/etc полиморфизм вызван наследованием. Откажитесь от этой ложной веры, и вам откроются динамические языки.

по сути, в Python нет такого интерфейса, как"понимание того, что некоторые методы могут быть вызваны". Довольно волнистые руки и академическое звучание, нет? Это означает, что поскольку вы вызываете "говорить", вы явно ожидаете, что объект должен иметь метод "говорить". Просто, да? Это очень Лисков-Ян в том, что пользователи класса определяют интерфейс, хорошая концепция дизайна, которая приводит вас к более здоровому TDD.

Итак, что осталось, как вежливо удалось избежать другого плаката, трюк с обменом кодом. Вы могли бы написать такое же поведение в каждом "дочернем" классе, но это было бы излишним. Проще наследовать или смешивать функции, которые инвариантны в иерархии наследования. Меньший, сухой код лучше в целом.

Это не наследование, которое утка-типизация делает бессмысленным, это интерфейсы - как тот, который вы выбрали при создании всего абстрактного класса животных.

Если бы вы использовали класс животных, который вводит некоторое реальное поведение для его потомков, то классы собак и кошек, которые ввели некоторое дополнительное поведение, были бы причиной для обоих классов. Только в случае класса-предка, не вносящего никакого фактического кода в классы-потомки, ваш аргумент правильный.

поскольку Python может непосредственно знать возможности любого объекта, и поскольку эти возможности изменчивы за пределами определения класса, идея использования чистого абстрактного интерфейса, чтобы "сказать" программе, какие методы могут быть вызваны, несколько бессмысленна. Но это не единственный и даже не главный пункт наследования.

вы можете обойти наследование в Python и почти на любом другом языке. Это все о повторном использовании кода и упрощении кода, хотя.

просто семантический трюк, но после создания ваших классов и базовых классов вам даже не нужно знать, что возможно с вашим объектом, чтобы увидеть, можете ли вы это сделать.

скажем, у вас есть d, который является собакой, которая подкласс животное.

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

Если доступно все, что ввел пользователь, код будет работать правильно метод.

С помощью этого вы можете создать любую комбинацию млекопитающих / рептилий / птиц гибридное чудовище, которое вы хотите, и теперь вы можете заставить его сказать " лай!"во время полета и торчит его раздвоенный язык, и он будет обращаться с ним правильно! Получайте удовольствие от этого!

Я не вижу особого смысла в наследство.

каждый раз, когда я когда-либо использовал наследование в реальных системах, я обжегся, потому что это привело к запутанной сети зависимостей, или я просто вовремя понял, что мне было бы намного лучше без него. Теперь я стараюсь избегать этого как можно больше. Я просто никогда не использую его.

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

Джеймсу Гослингу однажды на пресс-конференции задали такой вопрос: "если бы вы могли вернуться и сделать Java по-другому, что бы вы сделали оставить?". Его ответом были" занятия", над которыми раздавался смех. Однако он был серьезен и объяснил, что на самом деле проблема заключалась не в классах, а в наследовании.

Я как бы рассматриваю это как наркотическую зависимость - это дает вам быстрое решение, которое чувствует себя хорошо, но в конце концов, это портит вас. Под этим я подразумеваю, что это удобный способ повторного использования кода, но он вызывает нездоровую связь между дочерним и родительским классом. Изменения в родителе могут нарушить работу ребенка. Ребенок зависит от родителя для определенной функциональности и не может изменить эту функциональность. Поэтому функциональность, предоставляемая ребенком, также привязана к родителю - вы можете иметь только то и другое.

лучше предоставить один единственный клиентский класс для интерфейса, который реализует интерфейс, используя функциональность других объектов, которые составлены во время построения. Делая это через правильно конструированные интерфейсы, все соединение можно исключить и мы обеспечиваем сильно composable API (это ничего нового - большинство программистов уже делают это, просто недостаточно). Обратите внимание, что реализующий класс не должен просто предоставлять функциональность, иначе клиент должен просто использовать составленные классы напрямую-it должны сделайте что-то новое, объединив эту функциональность.

есть аргумент из лагеря наследования, что чистые реализации делегирования страдают, потому что они требуют много методов "клея", которые просто передают значения через цепь делегация''. Однако это просто изобретение дизайна, подобного наследованию, с использованием делегирования. Программисты со слишком большим количеством лет работы с проектами на основе наследования особенно уязвимы для попадания в эту ловушку, поскольку, не осознавая этого, они будут думать о том, как они будут реализовывать что-то с помощью наследования, а затем преобразовывать это в делегирование.

правильное разделение проблем, как в приведенном выше коде, не требует методов клея, так как каждый шаг на самом деле добавить значением, поэтому они на самом деле не являются "клеевыми" методами вообще (если они не добавляют ценности, дизайн испорчен).

Это сводится к следующему:

• для многоразового кода каждый класс должен делать только одну вещь (и это хорошо).

• наследование создает классы, которые делают больше чем одна вещь, потому что они вперемешку с родительскими классами.

• поэтому использование наследования делает классы, которые трудно использовать повторно.

еще один маленький момент заключается в том, что 3-й пример op, вы не можете вызвать isinstance(). Например, передавая ваш 3-й пример другому объекту, который принимает и" животное " типа вызовов говорят на нем. Если вы этого не сделаете, вам придется проверить тип собаки, тип кошки и так далее. Не уверен, если проверить экземпляр действительно "весть", из-за позднего связывания. Но тогда вам придется реализовать какой-то способ, чтобы AnimalControl не пытался бросать типы чизбургеров в грузовик, потому что чизбургеры не делают говорить.

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"

классы в Python в основном просто способы группировки кучу функций и данных.. Они отличаются от классов в C++ и подобных..

я в основном видел наследование, используемое для переопределения методов суперкласса. Например, возможно, более Python'ish использование наследования будет..

from world.animals import Dog

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

конечно кошки не тип собаки, но у меня есть это (третья сторона) Dog класс, который отлично работает,за исключением the speak метод, который я хотите переопределить-это сохраняет повторную реализацию всего класса, просто так он мяукает. Опять же, пока Cat это не тип Dog, но кошка действительно наследует много атрибутов..

гораздо лучший (практический) пример переопределения метода или атрибута-это то, как вы меняете user-agent для urllib. Вы в основном подкласс urllib.FancyURLopener и изменить атрибут версии (из документации):

import urllib

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

urllib._urlopener = AppURLopener()

другой способ исключения используются для Исключения, когда наследование используется более "правильным" способом:

class AnimalError(Exception):
    pass

class AnimalBrokenLegError(AnimalError):
    pass

class AnimalSickError(AnimalError):
    pass

..затем вы можете поймать AnimalError, чтобы поймать все исключения, которые наследуют от него, или специфический, как AnimalBrokenLegError