Q
ApiUser, ApiPost, ApiMessage
Size: a a a
2020 April 25
EC
Файл из 60 строчек - нет, интерфейс с 60 методами - ещё как.
Там писали про 15-25. Берём среднее - 20, по три строки на метод включая пустую строку. В чем тут проблема?
КР
Evgeny Cherkasov
Там писали про 15-25. Берём среднее - 20, по три строки на метод включая пустую строку. В чем тут проблема?
Даже 25 методов - перебор. Норм если мааааксимум 7. Дальше надо разбивать.
EC
Нет, конечно. Просто удобно, когда api по фичам/функционалу разбиты
Ну удобство понятие относительное. Кому то наоборот неудобно плодить кучу файлов.
EC
Даже 25 методов - перебор. Норм если мааааксимум 7. Дальше надо разбивать.
Откуда такая догма?
Q
Evgeny Cherkasov
Ну удобство понятие относительное. Кому то наоборот неудобно плодить кучу файлов.
Если работаешь не один - есть разница
КР
Evgeny Cherkasov
Откуда такая догма?
Выведена эмпирическим путём. Сколько человек у тебя в команде?
EC
Если работаешь не один - есть разница
Если над фичами работают разные люди и они мало связаны, то соглашусь.
Q
Я бы просто очень сильно огорчился, если бы в проекте было ~ 20 фич, на каждую по ~ 5 эндпоинтов и всё в одном месте...
Q
Достаточно того неудобства, что всё равно приходится держать один файл со списком всех модулей di/sl... Так еще и api...
EC
Я бы просто очень сильно огорчился, если бы в проекте было ~ 20 фич, на каждую по ~ 5 эндпоинтов и всё в одном месте...
Ну это уже 100 методов. Изначально речь шла о 20 )
Q
Evgeny Cherkasov
Ну это уже 100 методов. Изначально речь шла о 20 )
Ну, необходимо удерживать привычку всегда использовать более удобный подход, даже если работаешь один, думай что работаешь в команде )
Q
Потом не придеться приседать, когда с сингла вольешься в коллектив )
D
вообще довольно спорное удобство. не всегда можно удачно кластеризовать методы по фичам, будет получаться то интерфейс с одним методом, то с десятью методами. возможно иногда фичи будут пересекаться и придётся таскаться с несколькими зависимостями на интерфейсы нетворкинга
D
но поднимать панику и делать заявления как выше, когда у тебя апи на двадцать методов -- точно рано
Q
вообще довольно спорное удобство. не всегда можно удачно кластеризовать методы по фичам, будет получаться то интерфейс с одним методом, то с десятью методами. возможно иногда фичи будут пересекаться и придётся таскаться с несколькими зависимостями на интерфейсы нетворкинга
Проблема провайдить две репы в UseCase/Interactor ?
Q
Я создаю репы с датасорсами для сущностей, а не фич
D
Проблема провайдить две репы в UseCase/Interactor ?
скорее два класса с методами api в репу
Q
Если две фичи пересекаются, они достойны быть одной фичей
D
не всегда 🤷♂