Я не агитирую за перенос интерфейса в модуль-производитель (реализацию), а обращаю внимание на то, что отсутствие явного указания на реализацию интерфейса вводит в заблуждение разработчиков и может исказить логические зависимости между элементами.
Например, когда сначала создается реализация, а под нее уже потом пишется интерфейс.
Разница только в том, смотрите ли вы на implements или на информацию в своей IDE.
Ну это похоже на «сначала создаем себе трудности, потом их героически преодолеваем».
но это не причина считать, что все остальные некомпетентны
Так если начинают спорить по «очевидным вещам», что еще думать? Одно дело понимать и признавать, что есть проблема/последствия. Другое дело упорно не хотеть это видеть.
Думаю, что кроме переписки, можно насобирать еще кучу метаданных: номер сотового, содержимое адресной книги, распорядок дня (при временной привязке ip-адреса клиента) и т.п.
… и еще дополню по поводу мозговыносительной рекомендации, что в том виде, в котором она приведена мне от нее виден только вред как минимум по двум причинам:
1) если смотреть на нее, как на вариант реализации DI, то «re-utilization of the lower layer components is difficult»;
2) без ясного пояснения причин, без понимания логических связей и без указания ссылок на её (рекомендации) намерения очень легко неправильно понять и наклонировать интерфейсов во всех местах, где используется один вариант реализации. И свойства языка Go не препятствуют этому.
Кстати, по поводу первой реализации в wiki-статье прямо упомянуто:
...In this version of DIP, the lower layer component's dependency on the interfaces/abstracts in the higher-level layers makes re-utilization of the lower layer components difficult...
Могу прокомментировать, что я описал то, что в статье относится к: ...A more flexible solution extracts the abstract components into an independent set of packages/libraries...
А в первом варианте реализации DI (по ссылке в Wiki) упомянутый Go-программист упорно не видит, что есть связь между high-level и low-level components, потому что нет явного implements.
… и вторая, что конкретно в Го реализации не должны явно указывать, что они реализуют (этот ход мыслей мне понятен, но всё же спросите себя, так ли вам нужно видеть ...implements MyPrettyListener в исходнике...
Именно так. Да, мне хочется это видеть, что бы иметь представление о намерении разработчика, что бы иметь хороший инструмент рефакторинга и не иметь «false positive» ошибок срабатывания в IDE при поиске реализации интерфейсов.
Что плохого в желании иметь больший порядок в коде?
… а у этих, с duck typing, и вовсе проверка в рантайме наступает, в недрах кода, когда у обьекта внезапно не оказывается нужной функции на борту. Некомпетентны от рождения?.
Чем отличает хороший специалист от плохого? Хороший, даже если и отступает по каким-либо причинам от канонов, то понимает всю тяжесть последствий. А плохой, делая ошибки, всецело уверен в своей правоте и будет упорно доказывать, что он прав.
Хм, а вы, решив, что интерфейс принадлежит реализации
Что значит интерфейс принадлежит реализации? Интерфейс — это спецификация. Согласно этой спецификации можно использовать объект, либо согласно спецификации создать объект-реализацию.
На всякий случай, прочтите обсуждение сначала, вдруг окажется, что мы говорим об одном и том-же.
И мне это понятно, в C# или Java нам нужно «импортировать» библиотеку/пакет который объявляет «интерфейс», а в Go не нужно.
«Они» думают, что если не нужно «объявлять интерфейс», то и сущности получаются несвязанными. Хотя логическая связь никуда не девается и должна упоминаться в документации.
… Правда, как здоровый минус, мы бы попутно убили гошную возможность отделения интерфейса от реализации, больше никаких интерфейсов не стороне пользователя...
Дополню. Go-разработчик, увидев рекомендацию о "...Go interfaces generally belong in the package that uses values of the interface type..." возьмет и размножит декларацию интерфейса во всех местах (пакетах), где он ему понадобится.
Например, когда сначала создается реализация, а под нее уже потом пишется интерфейс.
Ну это похоже на «сначала создаем себе трудности, потом их героически преодолеваем».
Так если начинают спорить по «очевидным вещам», что еще думать? Одно дело понимать и признавать, что есть проблема/последствия. Другое дело упорно не хотеть это видеть.
1) если смотреть на нее, как на вариант реализации DI, то «re-utilization of the lower layer components is difficult»;
2) без ясного пояснения причин, без понимания логических связей и без указания ссылок на её (рекомендации) намерения очень легко неправильно понять и наклонировать интерфейсов во всех местах, где используется один вариант реализации. И свойства языка Go не препятствуют этому.
...In this version of DIP, the lower layer component's dependency on the interfaces/abstracts in the higher-level layers makes re-utilization of the lower layer components difficult...
Могу прокомментировать, что я описал то, что в статье относится к:
...A more flexible solution extracts the abstract components into an independent set of packages/libraries...
А в первом варианте реализации DI (по ссылке в Wiki) упомянутый Go-программист упорно не видит, что есть связь между high-level и low-level components, потому что нет явного implements.
Именно так. Да, мне хочется это видеть, что бы иметь представление о намерении разработчика, что бы иметь хороший инструмент рефакторинга и не иметь «false positive» ошибок срабатывания в IDE при поиске реализации интерфейсов.
Что плохого в желании иметь больший порядок в коде?
Чем отличает хороший специалист от плохого? Хороший, даже если и отступает по каким-либо причинам от канонов, то понимает всю тяжесть последствий. А плохой, делая ошибки, всецело уверен в своей правоте и будет упорно доказывать, что он прав.
Что значит интерфейс принадлежит реализации? Интерфейс — это спецификация. Согласно этой спецификации можно использовать объект, либо согласно спецификации создать объект-реализацию.
На всякий случай, прочтите обсуждение сначала, вдруг окажется, что мы говорим об одном и том-же.
«Они» думают, что если не нужно «объявлять интерфейс», то и сущности получаются несвязанными. Хотя логическая связь никуда не девается и должна упоминаться в документации.
Якобы, в Go можно разделить интерфейс и реализацию, а, например, в Java-нет:
… Правда, как здоровый минус, мы бы попутно убили гошную возможность отделения интерфейса от реализации, больше никаких интерфейсов не стороне пользователя...
По-моему, каша у них в голове на этот счет.
Как вам такой поворот событий?
То, что вы описали — все так.
Как говорится, самое интересное в статье — это комментарии :-)
Это не Приусы, а Лексусы. Например, RX400h:
Мда… чего только на этом свете не бывает. Запрет на хобби.