Comments 3
Хочется и по содержанию статьи проехаться и по личности... походу я так и сдохну с отрицательной кармой :)
Автор, ты - стажер, и тебе рано еще писать технические статьи, наберись опыта. Формально ты прав, и формально так можно делать. Но этот подход НЕ полулярный, и так НЕ делают. Потому что помимо одного репозитория и экземпляра Retrofit, будут еще репозитории (внезапно), API, которые ты получаешь из Retrofit, другие сущности, совершенно не связанные с сетевой активностью. Поддержка файла с таким подходом превратится в ад при наличии сколь-нибудь чуть более сложной логики, чем единственный репозиторий. Принцип Single Responsibility придуман не просто так. Дели по смыслу ответственности даже модули в DI, не стоит усложнять себе жизнь на ровном месте.
Я как-то писал практический гайд по Hilt для новичков
Добрый день! Спасибо за ваш комментарий и уделённое время моей статье.
Однако не могу согласиться с вами по ряду пунктов.
Во-первых, вы критикуете пример за то, что в одном модуле смешаны репозиторий и Retrofit и говорите о принципе единственной ответственности. Но суть статьи была в другом - объяснить понятие и роль companion object и разницу между @Provides и @Binds в Hilt. Пример в статье был спроектирован намеренно минималистичным, чтобы сфокусировать внимание читателя на синтаксисе (interface + companion object), а не на архитектуре. Утверждать, что автор предлагает так проектировать Hilt-модули на основе одного простого примера - некорректно. Это то же самое, что обвинять учебник математики за наличие примеров 2+2, а не интегралов.
Во-вторых, фразы «ты - стажер», «тебе рано еще писать статьи» - это не аргументы, а тем более в профессиональном сообществе.
Я прекрасно понимаю, что в реальном проекте стоит делить модули по фичам или слоям (NetworkModule, DatabaseModule, UseCaseModule и т.д.). Но если бы я в статье приводит десятки примеров с 30+ зависимостями, читатель потерял бы суть.
Задело? Окей, я попробую объяснить, как я это воспринимаю.
Читаю статью и вижу:
Может, написать отдельно interface со своими
@Binds-методами, и отдельно object со своими@Provides-методами? Получится неудобно
Первая моя мысль: "Автор - сраный диверсант. Сейчас джуны начитаются, а потом будут такую хуиту на ревью приносить." Потом я захожу в профиль и вижу, что написано "стажер" и "Люблю промышленную разработку! Изучаю Android-разработку на Kotlin...". Моя вторая мысль: "Стажер открыл магию статики в Kotlin".
Комментарий я все-таки решил написать, но писать "КГ/АМ" как-то не сильно конструктивно, поэтому я немного раскрыл мысль, почему этот "креатив - говно". Тем более ты же буквально сейчас сам написал:
Я прекрасно понимаю, что в реальном проекте стоит делить модули по фичам или слоям
Если в реальном проекте твой подход со статикой используется чуть более чем никогда (возможно в очень-очень редких случаях и с полным пониманием зачем и почему, и то вряд ли так будут делать), то зачем ты вообще это все написал?
Однако, я прошу прощения за мой резкий тон. Тут я не прав, признаю.
Зачем нужен companion object в Hilt-модулях