VS
Volodymyr Melko
ну типа если это не девайс детектор, а сервис который ходит по сети, то что ты будешь делать?
Принимаем транспорт в конструктор - тестим
Size: a a a
2020 September 24
VS
всеравно все конвертится в машинный код, может сразу на нем писать?
Короче пиши статик методы, тогда точно нигде new не будет
DT
можно через DI пихать фабрику, хоть какая-то развязка будет
VS
можно через DI пихать фабрику, хоть какая-то развязка будет
Обьекты со стейтом в DI пихать нехорошо. Мы тут не про фабрику говорим
VM
Vlad Sobenko
Принимаем транспорт в конструктор - тестим
да, но если сервис в конструктор принимает много чего, тебе много чего нужно мокать. А еще мокать нужно то, что в сервис через сеттер передается. Короче вместо бизнес логики твой тест будет содержать описание моков для твоей зависимости. А мог бы быть только мок самой зависимости
VS
Volodymyr Melko
да, но если сервис в конструктор принимает много чего, тебе много чего нужно мокать. А еще мокать нужно то, что в сервис через сеттер передается. Короче вместо бизнес логики твой тест будет содержать описание моков для твоей зависимости. А мог бы быть только мок самой зависимости
Бред
VM
Vlad Sobenko
Бред
вот и я говорю, что бред
DT
Vlad Sobenko
Обьекты со стейтом в DI пихать нехорошо. Мы тут не про фабрику говорим
Объект со стейтом создаст стейтлесс фабрика
VM
зачем в методе делать то, с чем вполне справится контейнер
VS
Volodymyr Melko
вот и я говорю, что бред
Как ты обьект со стейтом в DI засунешь?
VM
Vlad Sobenko
Как ты обьект со стейтом в DI засунешь?
подойди с другой стороны, зачем создавать сервисы со стейтом?
DT
Смысл убрать полное зацепление на конкретном классе
VS
Volodymyr Melko
подойди с другой стороны, зачем создавать сервисы со стейтом?
А причём тут сервисы?
SB
высокий каплинг с нулевым кохиженом?
new DateTime зло?
DT
new DateTime зло?
Все зло кроме пива)
VM
намного проще, когда сервисы как чистые функции и результат их работы не зависит от внутреннего стейта, а лишь от переданных аргументов.
Конечно всеравно гдето на границах системы будут сервисы зависящие от стейта и производящие сайд эффекты, но зачем делать их там, где можно не делать
Конечно всеравно гдето на границах системы будут сервисы зависящие от стейта и производящие сайд эффекты, но зачем делать их там, где можно не делать
VS
Смысл убрать полное зацепление на конкретном классе
Ну перенесёшь в другой. Это норм. Я про конкретно этот случай говрю, что был в коде
DT
Vlad Sobenko
Ну перенесёшь в другой. Это норм. Я про конкретно этот случай говрю, что был в коде
Да, и у тебя конкретно этот функционал не будет иметь в зависимостях конкретную штуку
SB
Volodymyr Melko
намного проще, когда сервисы как чистые функции и результат их работы не зависит от внутреннего стейта, а лишь от переданных аргументов.
Конечно всеравно гдето на границах системы будут сервисы зависящие от стейта и производящие сайд эффекты, но зачем делать их там, где можно не делать
Конечно всеравно гдето на границах системы будут сервисы зависящие от стейта и производящие сайд эффекты, но зачем делать их там, где можно не делать
логика в севисах данные в структурах и дивут отдельно?
VM
new DateTime зло?
в некоторых случаях да, но обычно создание дто\моделей не зло. Зло - создание сервисов