Есть ли какая-либо точка для интерфейсов на динамических языках?

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

, Но если Ваша функция ожидает большой набор методов, легче проверить если поддержка объектов интерфейс затем для проверки на поддержку каждого отдельного метода.

Хватит пытаться писать Java на динамическом языке.

Если бы вы чувствовали, что должны, вы могли бы реализовать своего рода интерфейс с функцией, которая сравнивает методы / атрибуты объекта с заданной сигнатурой. Вот очень простой пример:

file_interface = ('read', 'readline', 'seek')

class InterfaceException(Exception): pass

def implements_interface(obj, interface):
    d = dir(obj)
    for item in interface:
        if item not in d: raise InterfaceException("%s not implemented." % item)
    return True

>>> import StringIO
>>> s = StringIO.StringIO()
>>> implements_interface(s, file_interface)
True
>>> 
>>> fp = open('/tmp/123456.temp', 'a')    
>>> implements_interface(fp, file_interface)
True
>>> fp.close()
>>> 
>>> d = {}
>>> implements_interface(d, file_interface)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 4, in implements_interface
__main__.InterfaceException: read not implemented.

Конечно, это не очень много гарантирует.

как PHP программист, способ, которым я вижу его, Интерфейс, в основном используется в качестве контракта. Это позволяет Вам сказать, что все, что использует этот интерфейс MUST, реализует данный набор функций.

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

Это все равно, что сказать, что вам не нужны явные типы в динамически типизированном языке. Почему бы вам не сделать все «var» и не документировать их типы в другом месте?

Это ограничение наложено на программиста программистом. Вам становится труднее выстрелить себе в ногу; дает меньше места для ошибок.

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

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

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

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

Мне, однако, нравятся некоторые преимущества строгой типизации - прежде всего, я фанат раннего обнаружения ошибок. Я пытаюсь использовать «интерфейсное» абстрактное определение суперкласса.

class InterfaceLikeThing( object ):
    def __init__( self, arg ):
        self.attr= None
        self.otherAttr= arg
    def aMethod( self ):
        raise NotImplementedError
    def anotherMethod( self ):
        return NotImplemented

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

Ну, в первую очередь, правильно, что Ruby не имеет Интерфейса, как, но у них есть смешивание, которое берет так или иначе лучший из и из интерфейсов и из абстрактных классов с других языков.

главная цель интерфейса состоит в том, чтобы гарантировать, что Ваш объект должен реализовать ВСЕ методы, существующие в самом интерфейсе.

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

В таком языке, как PHP, где несуществующий вызов метода приводит к фатальной ошибке и выводит из строя все приложение, тогда интерфейсы yes имеют смысл.

На таком языке, как Python, где вы можете перехватывать и обрабатывать недопустимые вызовы методов, это не так.

Rene, прочитал мой ответ в "Лучшие практики для Проектирования Больших Систем на Динамическом Языке" вопрос здесь на StackOverflow. Я обсуждаю некоторые преимущества выдачи свободы динамических языков сэкономить усилия по разработке и упростить представляющих новых программистов к проекту. Интерфейсы, когда используется правильно, значительно способствуют записи надежного программного обеспечения.

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

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

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

Python также имеет Mixins, таким образом, Вы могли иметь, создают Интерфейсный класс путем определения Mixin наличие pass для каждой реализации метода, но это действительно не дает Вам много значения.

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

Для большинства проектов среднего размера все, что вам нужно, - это печатать на утке.

Да, есть смысл

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

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

Интерфейсы на самом деле добавляют определенную степень динамической подобной Ленгу гибкости на статические языки, которые имеют их, как Java. Они предлагают способ запросить объект, для которых контрактов он реализует во времени выполнения .

, Что порты понятия хорошо на динамические языки. В зависимости от Вашего определения "динамичного" слова, конечно, который даже включает Objective C, который использует Протоколы довольно экстенсивно в Какао.

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

В Ruby, который я мог бы спросить

object.respond_to? :sync

Так, да, это имеет метод, названный "синхронизацией", независимо от того, что это означает.

В Objective C я мог бы попросить, чтобы чему-то подобному, т.е. "этому взгляду/обходу/шарлатану понравилось что-то, что синхронизируется?":

[myObject respondsToSelector:@selector(sync)]

Еще лучше, за счет некоторого многословия, я могу попросить, чтобы чему-то более определенному, т.е. "этому взгляду/обходу/шарлатану понравилось что-то, что синхронизируется с MobileMe?":

[myObject respondsToSelector:@selector(sync:withMobileMeAccount:)]

Это - утка, вводящая вниз к уровню разновидностей.

, Но действительно спросить объект, обещает ли это реализовать синхронизацию к MobileMe...

[receiver conformsToProtocol:@protocol(MobileMeSynchronization)]

, Конечно, Вы могли реализовать протоколы, просто проверив на присутствие серии селекторов рассмотрение определения протокола/утки, и если они достаточно конкретны. В которой точке протокол является просто сокращением для большого ломтя ужасного responds_to? запросы и немного очень полезного синтаксического сахара для компилятора/IDE для использования.

Интерфейсы/протоколы являются другим размером метаданных объекта, которые могут использоваться для реализации динамического поведения в обработке тех объектов. В Java компилятор просто, оказывается, требует такую вещь для нормального вызова метода. Но даже динамические языки как Ruby, Python, Perl, и т.д. реализуют понятие типа, который идет вне просто, "на какие методы объект отвечает". Следовательно ключевое слово класса. JavaScript является единственным действительно наиболее часто используемым языком без того понятия. Если у Вас есть классы, то интерфейсы имеют смысл, также.

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

кроме того, упомянул кто-то еще mixins. Ruby mixins является способом совместно использовать код - например, они касаются реализации класса. Интерфейсы/протоколы об интерфейсе класса или объекта. Они могут на самом деле дополнить друг друга. У Вас мог бы быть интерфейс, который определяет поведение и один или несколько mixins, которые помогают объекту к реализация то поведение.

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

Python 3000 будет иметь Абстрактные базовые классы . Определенно стоящий чтения.