DjangoBB LoFi version

Полная версия: Общие методы для группы классов

Начало » Python для новичков » Общие методы для группы классов

1 2 3 4 5 6

py.user.next

Окт. 4, 2017 18:28:31

Slow
На очень большом классе задач композиция наоборот проигрывает наследованию, как с точки зрения сопровождения кода, так и производительности.

Давай пример конкретный. Вот я привёл Django, который монолитный и больше не будет меняться никогда, потому что переписывать его нереально. Почему он монолитный? Потому что всё от всего зависит. Да и дерево классов ты обязан полностью загрузить перед тем, как начать что-то делать. При соединении разрозненных объектов ты можешь ничего не подгружать, если оно не нужно. На что уйдёт больше времени?

Slow

Окт. 4, 2017 18:46:45

py.user.next

Во-первых, я вам не тыкал. Думаю, и не буду.
Во-вторых, я там малость отредактировал предыдущее сообщение (
Композицию взял, потому что у меня есть устойчивая связь в мозгах между ассоциацией и композицией как подклассом ассоциации. Аггрегация из той же оперы - подкласс ассоциации.
)

Джанго как (контр-)пример архитектуры, это вообще весело. Даже если не рассматривать тот факт, что местами ребята застряли в 90х, тем не менее, они развиваются, меняют модели, дропают депрекейты, и прочая, прочая, прочая.
И перекладывают, конечно, головную боль по обновлению на консьюмеров фреймворка, но ведь это уже другая история.

Что значит “загружать дерево классов”? Вы имеете в виду необходимость инициализации предков в процессе инициализации потомка? Ну да, небыстрая операция. Но однократная. И поведение объекта всегда детерминировано, хотя конечно для питона, с его возможностями, это и не обязательно.

Но вот “ничего не подгружать если оно не нужно” предполагает, что мы должны в рантайме проверять, а подгрузили ли мы, это как минимум. А еще возможны кейсы, где у нас логика выбора загружаемого может быть нетривиальна.
И, хотя это субъективно, код с ассоциациями читается хуже, чем код с наследованием.

Больше того, ассоциации всё-таки используются для описания связей между объектами, а не как замена наследования.
Вот вам на почитать, там хорошо расписано, что и когда применять
https://www.thoughtworks.com/insights/blog/composition-vs-inheritance-how-choose

Ассоциации - не серебряная пуля. Им есть своё место в жизни, но они ни в коей мере не замена.

py.user.next

Окт. 4, 2017 19:15:26

Slow
Вот вам на почитать, там хорошо расписано, что и когда применять
https://www.thoughtworks.com/insights/blog/composition-vs-inheritance-how-choose

Что-то не впечатлило как-то. Он же может поменять своё мнение там типа “ой, ребята, я ошибся немного, вношу правку, терь я думаю вот так”. Это же блог какой-то.
Он говорит там “если у вас виджет, наследуйте его от виджета”, я же спрашиваю “зачем?”. Он придерживается принципа “код должен быть красивым”. Слабоватая аргументация.

У меня же аргументация: я смогу в любой момент расцепить это обратно, никакая иерархия меня не сдерживает, думать мне о ней не надо.

Slow
Что значит “загружать дерево классов”?

Нужно всё в памяти держать всё время. Ты не можешь подгружать это по частям, только когда надо.

Slow
предполагает, что мы должны в рантайме проверять, а подгрузили ли мы, это как минимум.

Нам что-то понадобилось - мы это подгрузили. Оно может вообще в другом модуле находиться. А с наследованием такое не прокатит, так как подгружать надо всё и сразу.

FishHook

Окт. 4, 2017 19:46:17

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

druidich92

Окт. 4, 2017 20:05:26

py.user.next
Наследования нужно избегать. Вместо него используют агрегацию, так как она не связывает код.Так что надо в классах тех работать с интерфейсами. А после того, как оно написано, нужно написать такие классы, которые реализуют эти интерфейсы. И когда они сделаны, надо сделать агрегацию - то есть сделать экземпляры этих реализаций и подать эти экземпляры снаружи через конструктор.

а как в питоне описывать интерфейсы ? их же нет в чистом питоне !

Rodegast

Окт. 4, 2017 20:31:08

> а как в питоне описывать интерфейсы ? их же нет в чистом питоне !

Совокупность атрибутов объекта как раз и образуют его интерфейс. Абстрактные классы в том виде как они есть в C++/C# в Python-е не используются т.к. утинная типизация.

py.user.next

Окт. 5, 2017 02:51:44

druidich92
а как в питоне описывать интерфейсы ?

Через класс. Интерфейс - это набор методов. В ООПшных языках часто используют базовый класс (когда нет конструкций для интерфейсов). Например, делаешь интерфейс Animal, а потом для него пишешь функцию, которая работает с экземпляром класса Animal. Потом от него наследуешься и делаешь классы Dog и Cat. И потом в ту функцию, которая работает с экземпляром Animal, ты можешь подавать как экземпляр Dog, так и экземпляр Cat, потому что у них те же методы есть. Интерфейсом здесь служит Animal. Но ты можешь и не наследоваться от Animal, а просто реализовать интерфейс Animal в каком-то классе. То есть необходимости в наследовании нет, чтобы использовать интерфейс.

  
>>> class Animal:
...     
...     def say(self):
...         raise NotImplemented
... 
>>> class Cat:
...     
...     def __init__(self, name):
...         self.name = name
...     
...     def say(self):
...         print("I'm a cat", self.name)
...     
...     def scratch(self):
...         print("Scratching...")
... 
>>> class Dog:
...     
...     def __init__(self, name):
...         self.name = name
...     
...     def say(self):
...         print("I'm a dog", self.name)
...     
...     def woof(self):
...         print("Woofing...")
... 
>>> 
>>> def animal_say(animal):
...     animal.say()
... 
>>> 
>>> for i in (Cat('1'), Dog('1'), Cat('2'), Dog('2')):
...     animal_say(i)
... 
I'm a cat 1
I'm a dog 1
I'm a cat 2
I'm a dog 2
>>>

FishHook

Окт. 5, 2017 06:18:32

1. Говорим о том, что наследование - антипаттерн.

2. В подтверждение своих доводов приводим пример

Например, делаешь интерфейс Animal, а потом для него пишешь функцию, которая работает с экземпляром класса Animal. Потом от него наследуешься и делаешь классы Dog и Cat.

3. Показываем код, где классы Dog и Cat от Animal не наследуются.

py.user.next

Окт. 5, 2017 06:39:46

FishHook
3. Показываем код, где классы Dog и Cat от Animal не наследуются.

Ты не видел что ли рекламу шампуня хэд энд шолдерс? Это называется два в одном. Я ему говорю, как делали раньше, а потом сразу показываю, как делают сейчас. Просто по старому стилю мы должны отнаследовать Dog и Cat, чтобы сделать то же самое, но при этом возникает дерево классов, которое нам нафиг не нужно. Теперь же я свободно могу отнаследоваться от Dog, не боясь, что это как-то зафиксирует код класса Animal ещё больше. Но и от Dog я наследоваться не буду, а сделаю то же самое. А теперь мы убираем класс Animal из программы и видим, что остальное не нужно переделывать, потому что оно не зависит от класса Animal. Dog и Cat остаются и живут спокойно, не заметив даже, что Animal больше нет.

FishHook

Окт. 5, 2017 06:59:43

py.user.next
Я ему говорю, как делали раньше, а потом сразу показываю, как делают сейчас.

Тот код, который ты показал, это то, как делают сейчас? Замечательно, объясни мне дураку, зачем в нем вообще нужен класс Animal? какова его цель и смысл, если он только определяется, но не используется.