DjangoBB LoFi version

Найти - Пользователи

Полная версия: Программные интерфейсы в Python.

Начало » Python для новичков » Программные интерфейсы в Python.

1 2 3 4

Андрей Светлов

Фев. 9, 2011 23:24:24

Kogrom
Но в любом случае, без рассмотрения утиной типизации и abc - это прыжок через 3 ступеньки.

Верно сказано!

Subideal Ox

Фев. 10, 2011 12:03:35

slavka
И так, есть ли в Python программные интерфейсы?

Насколько я понимаю, интерфейсы в Delphy, Java и C# - это костыль, необходимость которого вызвана отсутствием в этих языках множественного наследования и одновременным желанием это множественное наследование использовать. В python множественное наследование есть (как, например, в C++ или Eiffel). Поэтому и костыли не нужны.

Итого - для использования “аналогичного функционала” (который называется полиморфизмом) пользуйтесь множественным наследованием.

regall

Фев. 10, 2011 12:23:43

Subideal Ox
Насколько я понимаю, интерфейсы в Delphy, Java и C# - это костыль, необходимость которого вызвана отсутствием в этих языках множественного наследования и одновременным желанием это множественное наследование использовать. В python множественное наследование есть (как, например, в C++ или Eiffel). Поэтому и костыли не нужны.
Итого - для использования “аналогичного функционала” (который называется полиморфизмом) пользуйтесь множественным наследованием.

Почему вы рассматриваете интерфейсы в Java и C# как костыль, мне непонятно. Интерфейс описывает взаимодействие реализации (класса) с внешним миром, для чего он и создавался. Эти языки изначально спроектированы так, чтобы не использовать множественное наследование.

Проблема множественного наследования в C# и Java (если уж так нужно их использовать) решается несколькими путями:
1. Множественное наследование интерфейсов.
2. Вложенные классы.
3. Статические классы, вложенные в интерфейсы.
Может есть и другие пути, но они мне неизвестны.

Борисенков Сергей

Фев. 10, 2011 12:35:18

Здесь вроде неплохо разжевано:
http://habrahabr.ru/blogs/python/72757/

Subideal Ox

Фев. 10, 2011 12:58:06

regall
Почему вы рассматриваете интерфейсы в Java и C# как костыль, мне непонятно.

А почему в Java и C# нет множественного наследования?

regall

Фев. 10, 2011 13:08:02

Subideal Ox
А почему в Java и C# нет множественного наследования?

Спросите у Гослинга =). Насколько я помню основным аргументом при отказе от множественного наследования в Java была так называемая “diamond problem” в C++. То есть когда есть иерархия классов типа такой, и классы B и C содержат методы с одинаковыми именами:

        A
      /   \
     /     \
    B-----C
    \       /
     \    /
       D

Когда иерархия классов большая и разветвленная такая проблема часто возникает. В Java отказались от этого, чтобы не было соблазна напроектировать такие проблемы.

В Python есть MRO, который превращает иерархию в линейную структуру, таким образом класс D получит метод из класса C, а метод из класса B будет упущен.

Единственная возможность получить MRO конфликт - построить такую структуру:

 -----------
|           |
|    O      |
|  /   \    |
 - X    Y  /
   |  / | /
   | /  |/
   A    B
   \   /
     ?

Впрочем, это хорошо описано здесь: http://www.python.org/download/releases/2.3/mro/, так что не буду углубляться.

Subideal Ox

Фев. 10, 2011 14:55:51

regall
В Python есть MRO, который превращает иерархию в линейную структуру

Отлично. Добавлю, что кроме этого конфликты имен в Python можно разрешить явно, указав методы и аттрибуты какого из предков надо использовать. Все просто.

Но если решения так просты, то почему в Java нет MRO? Почему я должен возиться с интерфейсами (т.е. проблемы с повторным использованием кода), или со вложенными классами (проблемы с полиморфизмом), или искать какие-то синтетические решения?

regall

Фев. 10, 2011 15:26:51

Subideal Ox
Но если решения так просты, то почему в Java нет MRO?

Subideal Ox, уж извините, это уже вопросы не ко мне, так как я не очень компетентен в плане архитектуры и устройства JVM, не тянуло меня никогда лезть и копаться там =). Единственное, что могу добавить, что Java всегда борется с повышением быстродействия и т.д. и зачастую архитектурные решения Java принимаются под давлением потребностей повышения скорости выполнения. Такие вещи уже надо смотреть в конкретных реализациях JVM, а именно места, где выполняются блоки статической инициализации и загрузки классов в JVM.

Андрей Светлов

Фев. 10, 2011 15:42:04

regall
Единственное, что могу добавить, что Java всегда борется с повышением быстродействия

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

regall

Фев. 10, 2011 15:51:52

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

:lol: Блин. Очепятался, бывает =(