Как я могу обеспечить правильную конструкцию при соблюдении правила golang CodeReviewComments на интерфейсах?

Question

Правило Interfaces в официальном документе Go Code Review Комментарии говорит, что пакеты должны возвращать конкретные типы, а не интерфейсы.Мотивация для этого заключается в том, что:

... новые методы могут быть добавлены в реализации без необходимости масштабного рефакторинга.

, который я принимаю, может быть хорошей вещью.

Но что если тип, который я пишу, имеет зависимость, без которой он не может служить своей цели?Если я экспортирую конкретный тип, разработчики смогут создавать экземпляры без этой зависимости.Чтобы защитить код для отсутствующей зависимости, я должен проверить ее в каждой реализации метода и вернуть ошибки, если она отсутствует.Если разработчик пропустил какие-либо подсказки, чтобы не делать этого в моей документации, он или она не узнает о проблеме до времени выполнения.

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

Неужели я как-то не в духе, думая так?Является ли этика языка нормой, когда инкапсуляция не идеальна, чтобы дать разработчикам больше гибкости?

Answer 1

Вы можете ожидать, что разработчики прочитают предоставленный вами документ, и вы можете положиться на них, следуя установленным вами правилам.Да, ленивые разработчики время от времени бьют головой, но процесс разработки не обходится без необходимости учиться.Все нельзя сделать явным или принудительным, и все в порядке.

Если у вас есть экспортированный тип структуры Example и вы предоставляете функцию конструктора NewExample(), это явный признак того, что следует использовать NewExample()построить значения Example.Предполагается, что любой, кто пытается создать Example вручную, будет знать, какие поля должны быть установлены, чтобы он работал.Цель всегда состоит в том, чтобы сделать нулевое значение полностью функциональным, но если это не может быть достигнуто, функция конструктора - идиоматический путь.

Это не редкость, в стандарте есть бесчисленное множество примеров.библиотека, например http.Request, json.Encoder, json.Decoder, io.SectionReader, template.Template.

Вы должны убедиться, что если ваш пакет возвращает значения ваших структур, они должны (должны) быть правильно инициализированы.А также, если ожидается, что другие передадут значения созданных ими ваших структур, вы должны предоставить им простой способ создания допустимых значений ваших структур (функция конструктора).Являются ли значения пользовательских структур, которые другие разработчики создают сами, «допустимыми», это не должно вас беспокоить.