Добрый день! Спасибо за ваш комментарий и уделённое время моей статье.
Однако не могу согласиться с вами по ряду пунктов.
Во-первых, вы критикуете пример за то, что в одном модуле смешаны репозиторий и Retrofit и говорите о принципе единственной ответственности. Но суть статьи была в другом - объяснить понятие и рольcompanion objectи разницу между @Providesи@Bindsв Hilt. Пример в статье был спроектирован намеренно минималистичным, чтобы сфокусировать внимание читателя на синтаксисе (interface + companion object), а не на архитектуре. Утверждать, что автор предлагает так проектировать Hilt-модули на основе одного простого примера - некорректно. Это то же самое, что обвинять учебник математики за наличие примеров 2+2, а не интегралов.
Во-вторых, фразы «ты - стажер», «тебе рано еще писать статьи» - это не аргументы, а тем более в профессиональном сообществе. Я прекрасно понимаю, что в реальном проекте стоит делить модули по фичам или слоям (NetworkModule, DatabaseModule, UseCaseModule и т.д.). Но если бы я в статье приводит десятки примеров с 30+ зависимостями, читатель потерял бы суть.
Здравствуйте!
Идея с приложением для хранения паролей мне понравилась, возьму на заметку)
Спасибо за статью!
Добрый день! Спасибо за ваш комментарий и уделённое время моей статье.
Однако не могу согласиться с вами по ряду пунктов.
Во-первых, вы критикуете пример за то, что в одном модуле смешаны репозиторий и Retrofit и говорите о принципе единственной ответственности. Но суть статьи была в другом - объяснить понятие и роль
companion objectи разницу между@Providesи@Bindsв Hilt. Пример в статье был спроектирован намеренно минималистичным, чтобы сфокусировать внимание читателя на синтаксисе (interface+companion object), а не на архитектуре. Утверждать, что автор предлагает так проектировать Hilt-модули на основе одного простого примера - некорректно. Это то же самое, что обвинять учебник математики за наличие примеров 2+2, а не интегралов.Во-вторых, фразы «ты - стажер», «тебе рано еще писать статьи» - это не аргументы, а тем более в профессиональном сообществе.
Я прекрасно понимаю, что в реальном проекте стоит делить модули по фичам или слоям (
NetworkModule,DatabaseModule,UseCaseModuleи т.д.). Но если бы я в статье приводит десятки примеров с 30+ зависимостями, читатель потерял бы суть.