KD
Не то, чтобы это плохо, но пока не попробовал выглядит страшно:)
Size: a a a
2020 March 13
KD
В случае моков ты еще часто проверяешь, что эти данные ты запросил или их пробросили
Хм, не очень понял мысль. Можешь пример вкинуть?
AM
Вообще, для меня, как человека не работавшего по принципам DR — это выглядит всё довольно сложно и запарно.
Понимаю теорию и суть, но думая в контексте текущей разработки мне кажется, что код превратился бы в ту ещё кашу, т.к. вся обработка была бы в одном месте.
И какой-то условный:
Понимаю теорию и суть, но думая в контексте текущей разработки мне кажется, что код превратился бы в ту ещё кашу, т.к. вся обработка была бы в одном месте.
И какой-то условный:
presenter.buttonClick() превратился бы вval data = dataSource.getData()
val moreData = dataSource.getMoreData()
val result = useCase.doSomethingWithData(data, moreData)
view.showResult(result)
> т.к. вся обработка была бы в одном месте.
Мне кажется, это больше про чай, а не про ФП в целом.
Мне кажется, это больше про чай, а не про ФП в целом.
KD
> т.к. вся обработка была бы в одном месте.
Мне кажется, это больше про чай, а не про ФП в целом.
Мне кажется, это больше про чай, а не про ФП в целом.
Погоди. Тут вроде про DR было.
ML
Не то, чтобы это плохо, но пока не попробовал выглядит страшно:)
Это в тебе говорит ооп
AM
Ну так DR о структурировании бизнес-логики говорит примерно ничто, кроме того, что она должна быть чистой — т.е. опираться на обычные входные-выходные параметры функций
ML
Именно тот момент, когда тебе перестает быть страшно и является просветлением
KD
Это в тебе говорит ооп
Это во мне говорит боязнь странных портянок кода:))
Но может попробую в каком-нибудь пете поработать с этими подходами, глядишь и познаю дзен.
Но может попробую в каком-нибудь пете поработать с этими подходами, глядишь и познаю дзен.
AM
А сбор всей обработки в одном месте — это привет подходам вроде TEA, где всё собирается в один большой редьюсер
KD
Ну так DR о структурировании бизнес-логики говорит примерно ничто, кроме того, что она должна быть чистой — т.е. опираться на обычные входные-выходные параметры функций
Вот.
И вместо вызова, который внутри сделает всё необходимое — тебе надо самим делать каждый отдельный вызов и связывать всё воедино.
И вместо вызова, который внутри сделает всё необходимое — тебе надо самим делать каждый отдельный вызов и связывать всё воедино.
KD
Т.е. у тебя не будет вложенности из, например: View -> Presenter -> UseCase -> Repo -> DataSource.
А всё это будет в, например, презентере и обрабатываться там же.
А всё это будет в, например, презентере и обрабатываться там же.
KD
(как я понимаю)
I
Вообще, для меня, как человека не работавшего по принципам DR — это выглядит всё довольно сложно и запарно.
Понимаю теорию и суть, но думая в контексте текущей разработки мне кажется, что код превратился бы в ту ещё кашу, т.к. вся обработка была бы в одном месте.
И какой-то условный:
Понимаю теорию и суть, но думая в контексте текущей разработки мне кажется, что код превратился бы в ту ещё кашу, т.к. вся обработка была бы в одном месте.
И какой-то условный:
presenter.buttonClick() превратился бы вval data = dataSource.getData()
val moreData = dataSource.getMoreData()
val result = useCase.doSomethingWithData(data, moreData)
view.showResult(result)
Офигенно, моя любимая тема.
Запрашиваешь ВНАЧАЛЕ все данные, а потом трансформираешь информацию функциями
Запрашиваешь ВНАЧАЛЕ все данные, а потом трансформираешь информацию функциями
ML
Это во мне говорит боязнь странных портянок кода:))
Но может попробую в каком-нибудь пете поработать с этими подходами, глядишь и познаю дзен.
Но может попробую в каком-нибудь пете поработать с этими подходами, глядишь и познаю дзен.
ML
Вот.
И вместо вызова, который внутри сделает всё необходимое — тебе надо самим делать каждый отдельный вызов и связывать всё воедино.
И вместо вызова, который внутри сделает всё необходимое — тебе надо самим делать каждый отдельный вызов и связывать всё воедино.
Да, в этом трейдофф – тут не сделаешь переиспользуемого вороха сайд-эффектов. С другой стороны, переиспользование сайд эффектов это та ещё морока. Наверное сам не раз видел код в который инжектится какая-то "стратегия" чтобы где то в середине флоу чуть чуть изменить обработку
ML
По мне так нахуй так жить^W переиспользовать
KD
Думаю, что всё хорошо в меру:)
ML
Думаю, что всё хорошо в меру:)
Да, и "в мире нет черного и белого". Но из-за врожденной лени человеческого вида нужны "стратегии по умолчанию". Имхо, правильнее по умолчанию DR, потому что из него в "ворох сайд-эффектов" скатиться проще простого, если понадобится. А вот обратно уже сложняк
KD
Снова таки, с переиспользованием — и хорошим, и плохим — я сталкивался. А вот с реальным примером DR в проде — нет. Так что моё мнение слишком предвзято и субъективно.
Просто знаю и верю, что каждый подход имеет право на жизнь и считать, что что-то отвратительно и загубит всё, а что-то панацея от всех проблем — глупо.
Просто знаю и верю, что каждый подход имеет право на жизнь и считать, что что-то отвратительно и загубит всё, а что-то панацея от всех проблем — глупо.