почему интерфейсы в динамических / слабо типизированных языках?

Question

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

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

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

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

Какие преимущества вы на самом деле получаете от использования интерфейса в динамических / свободно типизированных языках, таких как PHP? Они великолепны, или это что-то, что реализуют более надежные ОО-языки, поэтому PHP также реализует это?

Answer 1

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

Например, если я создаю оболочку БД и она поддерживает поведения, которые вы регистрируете в начальной загрузке, то перед запускомваши поведения (например, sluggable), я проверю, что они реализуют мой "DB_Wrapper_Behaviour_Interface" с помощью:

if(!($behaviourObject instanceof DB_Wrapper_Behaviour_Interface)) {
    throw new Exception("Your behaviour doesn't implement my interface");
}

Answer 2

Проектирование по контракту усложняется без типов возврата, но не забывайте отдавать предпочтение «скажите», а не «спрашивайте».

Я считаю, что интерфейс - это что-то вроде ответственности.Вы кодируете и вам нужен соавтор.Вы просите это сделать что-то, потому что код, над которым вы работаете, не может сделать все.Итак, вы просите другой объект сделать что-то.Интерфейс гарантирует, что соавтор выполнит работу, но скрывает то, как он это сделал.

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

Answer 3

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

Answer 4

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