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

Question

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

PHP поддерживает интерфейсы. У Руби и Питона их нет. Таким образом, вы можете жить счастливо без них.

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

Итак, что ты думаешь? Разве ты не лучше без использования интерфейсы на динамических языках вообще?

Answer 1

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

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.

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

Answer 2

как программист PHP, как я понимаю, интерфейс в основном используется в качестве контракта. Это позволяет вам сказать, что все, что использует этот интерфейс, ДОЛЖНО реализовывать данный набор функций.

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

Answer 6

В дополнение к другим ответам я просто хочу указать, что в Javascript есть ключевое слово instanceof, которое будет возвращать true, если данный экземпляр находится где-нибудь в цепочке прототипов данного объекта.

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

MDN instanceof Reference

Answer 7

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

Основная цель интерфейса - убедиться, что ваш объект ДОЛЖЕН реализовать ВСЕ методы, присутствующие в самом интерфейсе.

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