Я должен определить интерфейсы на Утиных Типизированных языках?
Я как раз собираюсь записать свое первое приложение на утином типизированном языке (Groovy).
Если бы я должен был записать то же приложение на статическом типизированном языке тогда, то я должен был бы определить некоторые интерфейсы. Очевидно, из-за утиного ввода в Groovy они на самом деле не требуются. В данный момент я думаю, что могло бы иметь смысл определять их так или иначе как документацию методов, которые должны быть реализованы в различных объектах. Я упускаю суть?
3 ответа
Я недавно читал об этом здесь, на SO (и я не могу найти ссылку прямо сейчас, но это один из тех постов "Почему динамические языки хороши?" , и большой ответ С. Лотта с множеством комментариев), и ответ:
Вы могли бы. В частности, в Groovy вы можете определять интерфейсы на Java или Groovy и реализовывать их. Однако с утиной типизацией (которая позволяет Groovy, но также допускает явные типы) многие люди скажут: «Зачем беспокоиться?» Источником является его собственная документация, интерфейс находится в исходном коде, «используйте исходный код» и т. Д.
Лично это сводит меня с ума - мне нравятся проверки во время компиляции (или на самом деле, во время разработки), которые дает мне Java, но это уже другой спор. Если вы используете Groovy, то это потому, что вы хотите написать блестяще краткий и ясный код, который получается при утином вводе. В этом случае следует избегать интерфейсов, за исключением случаев, когда это необходимо.
Где они нужны? Между частями программы и в общедоступном API для программы (хотя они также могут быть абстрактными классами). В противном случае я бы сказал, что вам следует избегать их в языках с утиным типом. Это заставляет вас писать документацию по классам или писать настолько ясный код, что это одно и то же.
Я думаю, что это ужасная практика, ОДНАКО это часть смены парадигмы в сторону динамических языков. И я думаю, что если вы не будете достаточно отделять интерфейс от реализации, вы поймете «почему», стоящее за этим. Я до сих пор не делаю этого, хотя во многом это связано с тем, что код не повторяется (сохраняется СУХОЙ).
Edit: Получил некоторую ясность от компьютера :) Одна из основных причин НЕ отделять интерфейс от реализации - это уход от зависимости от типов . В утином наборе, как вы знаете, меня не волнует, является ли это реализатором интерфейса Vehicle (например). Меня волнует только то, есть ли у него метод go с двумя параметрами. Таким образом, чем больше вы работаете с интерфейсами, тем больше вы пишете Java на Groovy («вы можете писать Fortran на любом языке»). Этого следует избегать, поскольку новые языки открывают перед вами новые возможности.
Я не знаком с Groovy, но в целом нет, вам не нужно определять интерфейсы на языках со слабой типизацией.
Вы будете повторяться, если вам нужно изменить сигнатуру методов, вам нужно сделать это в двух местах, а не в одном.
Хотя интерфейсы в некоторой степени используются в качестве документации, на языке со слабой типизацией большинство программистов не ожидают наличия интерфейса и, следовательно, не будут искать интерфейс, если им нужна документация.
Для большинства динамических языков доступны хорошие IDE с автозавершением методов, что еще больше снижает потребность в отдельном интерфейсе.
В динамических языках методы могут быть привязаны и отключены. Следовательно, вы можете и, вероятно, получите объекты, которые не привязаны к интерфейсу. Наличие отдельного интерфейса может запутать людей, читающих ваш код.
Определение интерфейса - это своего рода документация внутри кода. В интерфейсе вы явно объявляете, что вы ожидаете от класса для удовлетворения ваших потребностей.
PS: Groovy - это не мой язык, поэтому я на самом деле не знаю , можно ли вообще определять там интерфейсы .