Comments 18
Если ваша IDE не может найти реализации, то это её недостаток, а не интерфейсов.
Удобный аргумент :) Возьму себе на вооружение.
Запуск компилятора для определения того, что структура реализует интерфейс — это сомнительный плюс. Да, стоимость этого ничтожна, но сам подход.
Ну и про утиную типизацию уже писали, приватность интерфейса тоже довольно спорное преимущество, как мне кажется.
Язык GO кажется подходящим инструментом для развития больших проектов.
Ключевое слово "кажется"?!
Одна из самых полезных вещей, которую дает утиная типизация (и не только в Go, а вообще) — всегда можно пойти от реализации к абстракции (а не наоборот), не допуская преждевременного введения тысячи ненужных слоев этой самой абстракции.
Чтобы убедиться, что структура реализует интерфейс, достаточно запустить компилятор. Он покажет, каких методов не хватает.
Если писать на Go идеоматично, то такая проблема не должна возникать часто, потому что в Go принято интерфейсы делать максимально узкими.
Преимущества сомнительны. Особенно когда у вас есть N интерфейсов с пересекающимися методами и классы в которых они случайно "заимплечены". Никакая IDE не даст точного ответа, что имел автор такой лапши.
Интерфейсы больше полезны для документации кода и по ним удобно читать скелет модуля/системы.
Возвращаясь к аргументу про ИСР — если ваша ИСР не умеет экстрактить/рефакторить интерфейсы, то это её проблемы ))
Но при этом никто же не мешает использовать общие интерфейсы, если они действительно хорошо отделяются. Важно чтобы интерфейсы были небольшими, тогда проблем с большим количеством пересечений быть не должно.
Как вы документируете модуль через интерфейсы? Модуль — это же про реализацию. Разные модули могут реализовывать один и тот же интерфейс. У интерфейса немного своя документация. У модуля документация скорее про нюансы реализации.
В итоге код получается немного проще.
github.com/golang/go/wiki/CodeReviewComments#interfaces
Этот текст — курсовая работа студента?
Нет. Почему вы так думаете?
Стиль статьи очень походит на таковой в курсовых работах.
Бросаются в глаза такие вещи, как: 1) утверждения, выходящие за пределы темы (концовка статьи, заключение); 2) голословные утверждения. Например, Вы утверждаете, что интерфейсы Go лучше таковых в других языках, но ничего не пишете, о том, а каково оно у них, да и о каких языках речь-то? Примеры хороши, но они не доказывают, что интерфейсы Go лучше, так как сравнить их не с чем. 3) наличие спорных утверждений, например, об IDE. Это отдельная тема для обсуждения.
Вероятно, что все эти вещи и повлияли на то, что статью заминусовали.
1) В концовке я написал, что он подходит для больших проектов говоря об этом в контексте использования интерфейсов, поэтому я указал, что
Язык GO кажется подходящим инструментома не написал, что он точно является подходящим.
2) Я старался показать именно сильные стороны, показывая разницу с самым распространенным способом работы с интерфейсами в популярных языках как Java, C++, PHP. Но видимо да, нужно было привести примеры с других языков, чтобы было понятнее.
Видимо, нужно писать подробнее, раскрывая больше мыслей. Чтобы не было таких недопониманий и негативных реакций. Это моя первая статья на хабре.
Преимущества интерфейсов в GO