этот подход хорошо масштабируется с ростом количества ресурсов, гораздо лучше чем явный конструктор ручной ресолв зависимостей я не считаю недостатком, в идиоматическом го коде явное лучше неявного а главное полезное качество такого локатора - его портативность и модульность, к примеру сложная инициализация может быть распределена в по нескольким функциям которые координируются друг с другом используся локатор как состояние, при этом нет нужды копипастить списки типов в виде аргументов таковых функций отсутствие встроенной защиты от nil легко компенсируется (и должно в любом случае) тестами, так что это скорее теоретический недостаток, чем присущий реальному качественному проекту
Что за сложная инициализация? Почему она распределяется по нескольким функциям? И откуда у локатора взялось состояние? И о какой модульности идёт речь, если у вас в одном интерфейсе все зависимости? Если у вас есть ещё один компонент, где зависимостей больше или меньше, этот helloDeps становится бесполезным
сложная инициализация это ситуация в которой существует много ресурсов которые можно разделить на группы по их зависимостям, инициализацию такой группы можно делегировать функции и тем самым упростить общую процедуру, например ваш микросервис зависит от 5 других по хттп апи, инициализацию всех этих клиентов можно вынести в функцию ресурсы локатора - его состояние модульность происходит с одной стороны от композиции провайдеров (которые при росте системы и сами могут образовывать группы, типа "суперпровайдер"), с другой стороны сабинитерфейсы которые зависят только от подмножества ресурсов helloDeps декларирует требуемые ресурсы, если в приложении несколько сервис локаторов с разным содержимым, helloDeps примет только те которые содержат весь нужный список ресурсов, иначе ошибка компиляции
Обсуждают сегодня