Когда он был еще программистом, а не проповедником, мне он нравился больше. До того, как начал использовать технические платформы для пиара своего стартапа.
Так это, тимлид же все. Не по скраму. Оказалось, при хорошем тимлиде очень трудно втюхать фирме скрам-мастера. Эти роли конфликтуют и соревнуются за влияние и кол-во митингов, которые каждый может назначить. Тимлид, грешным делом, может навести порядок, а это прямая угроза эджайл коучу. Текущий тренд: тимлид — роль деспотичная, авторитарная. Ограничивает свободу и креативность команды. Вопиющая несправедливость в эпоху эгалитаризма. Только равенство и плоская иерархия, за все отвечает «команда» и никто в частности.
О, здравые мысли в комментариях! Хоть кто-то включает голову, а не дрочит на покрытие и пустые зеленые галочки. Статья Jim Coplien'a просто обязательна к прочтению. Вот она же в pdf: rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf. Тут на нее ссылается David Heinemeier Hansson: dhh.dk/2014/tdd-is-dead-long-live-testing.html. Немного о другом, но Dan Abramov про TDD: twitter.com/dan_abramov/status/1086418722124906497. Все это не последние люди в программировании, которым есть что сказать. Но это уже следующий уровень понимания, мерзкий голос рассудка, который тихо подкрадывается и обзывает тебя клоуном, каждый раз когда ты пишешь очередную пачку идиотских тестов вокруг «1+1 = 2», чтобы не просело покрытие.
Если я правильно понял, единственная причина по которой в проекте есть Kotlin/Native это то, что автор знаком с котлином. По хорошему, тут все должно быть на дарте, но все хотят писать на котлине, а не на дарте и как результат — «вот это вот все».
Хороший структурный обзор конференции. Но Виталий… так тянуть жилы из аудитории своим M1 (по шкале Mutko) английским, как это делали Вы — думал стул прожгу. Не щадили ни женщин, ни детей. Казалось бы, что Тинькофф (6 млн клиентов против 1 млн у N26) мог бы и получше. Успехов и приезжайте ещё, конечно!
Так в этом и смысл, Вы только подтвердили суть статьи. В отсутствии полной информации люди ударяются в иллюзии, чтобы не оставаться с неопределенностью.
Можно в декомпиленных исходниках, но проще всего в трафике. CLIENT_ID у них идет прицепом к каждому запросу, как queryParam. А CLIENT_SECRET будет в payload к sign_in запросу.
Если для поиграться с API в песочнице, то, в принципе, ключи есть в мобильном приложении. Там и API давно другой для web и mobile, а документация только по старому и вообще, проект выглядит немного дохленьким.
метод с inline + reified из java не вызвать. Интерфейс определенный в java это SAM, но, внезапно, интерфейс определенный в kotlin нет. В интерфейсах @JvmStatic/@JvmField не работает и тд. В какой-то степени это должно радовать, потому что в котлине есть фичи, которые невозможно повторить в джаве, но тогда нужно быть скромнее про 100% интероп.
Если в коде Interactor'a встречается слово "repository", то это не DIP. Я не знаю как еще объяснить. Интерфейсы, не интерфейсы уже на ваше усмотрение. С помощью Rx, например, оно и в Java без интерфейсов будет.
То, что объект больше не отвечает за создание другого объекта, а получает его в конструкторе еще не означает, что у вас инверсия зависимостей. Пока что это просто соблюдение SRP. DIP у вас будет, когда объекты из разных слоев будут общаться через промежуточные интерфейсы, а не напрямую. Тогда у вас пропадет жесткая связь между разными уровнями. Т.е. если Interactor явно дергает методы из Repository (пусть и внедренный через конструктор) — это не DIP, нет промежуточного интерфейса/контракта, который скроет Repository. Важно не путать эти связующие интерфейсы с личными интерфейсами, которые уже могут быть у этих объектов (какой-нибудь RepositoryInterface и тд.). Иллюстрация с вики должна лучше передать то, что я пытаюсь сказать: https://en.wikipedia.org/wiki/Dependency_inversion_principle
Еще раз вчитался в Ваш комментарий, кажется это правильное объяснение. Т.е. дело именно в семантике, мы не хотим чтобы UseCase зависел от чего-то, что относится к инфраструктуре. Другие объяснения, что это инверсия зависимостей, а инверсия всегда хорошо, кажутся притянутыми за уши.
Вы привели общее описание Loose coupling. С таким же успехом можно было инвертировать вообще все зависимости на этой схеме, а чё б и нет, столько гибкости! Но почему-то между Presenter и Interactor этого нет, а между Interactor и Repository есть. Видимо преследуется какая-то неочевидная выгода. Опять же, судя по коду (пример выше), который часто приводят под Clean Architecture, сами же авторы не сильно заморачиваются с инверсией на этом участке.
Спасибо, а зачем это делается? Какую проблему мы пытаемся решить, когда инвертируем зависимость между Interactor и Repository? Ведь направление запроса данных обратное от того, что нарисовано. Вот еще один пример на ту же тему: https://engineering.21buttons.com/clean-architecture-in-django-d326a4ab86a9. Судя по имплементации, Interactor просто использует Repository, получает его в конструкторе. Но это не соответсвует тому, что нарисовано. По хорошему, он должен был инвертировать зависимость, как вы описали выше. Но… зачем?
Я не уверен, что LiaminRoman получил ответ на вопрос. Точно так же привык, что UseCase тянет данные из Repository (или нескольких), добавляет нужную логику и передает выше. Но тогда направление на диаграмме было бы другим. Как конкретно Вы это реализуете, чтобы Repository был слоем выше, чем UseCase и главное зачем это делать, если в статье четко написано, то UseCase ближе к Presenter'ам? Почему просто не построить цепочку Presenter --> UseCase --> Repository?
чем больше мы узнаем информации о ком-то еще, тем больше мы склонны недолюбливать этого человека. «Хотя люди верят, что знание ведет к благосклонности, большее знание на самом деле приводит к уменьшению симпатии»
метод с
inline + reifiedизjavaне вызвать. Интерфейс определенный вjavaэтоSAM, но, внезапно, интерфейс определенный вkotlinнет. В интерфейсах@JvmStatic/@JvmFieldне работает и тд. В какой-то степени это должно радовать, потому что в котлине есть фичи, которые невозможно повторить в джаве, но тогда нужно быть скромнее про 100% интероп.Если в коде Interactor'a встречается слово "repository", то это не DIP. Я не знаю как еще объяснить. Интерфейсы, не интерфейсы уже на ваше усмотрение. С помощью Rx, например, оно и в Java без интерфейсов будет.
То, что объект больше не отвечает за создание другого объекта, а получает его в конструкторе еще не означает, что у вас инверсия зависимостей. Пока что это просто соблюдение SRP. DIP у вас будет, когда объекты из разных слоев будут общаться через промежуточные интерфейсы, а не напрямую. Тогда у вас пропадет жесткая связь между разными уровнями. Т.е. если Interactor явно дергает методы из Repository (пусть и внедренный через конструктор) — это не DIP, нет промежуточного интерфейса/контракта, который скроет Repository. Важно не путать эти связующие интерфейсы с личными интерфейсами, которые уже могут быть у этих объектов (какой-нибудь RepositoryInterface и тд.). Иллюстрация с вики должна лучше передать то, что я пытаюсь сказать: https://en.wikipedia.org/wiki/Dependency_inversion_principle
Гм, пожалуй нет. Просто constructor injection. В интеракторе поле репозитория, зависимость никуда не делась, инверсии нет.
Еще раз вчитался в Ваш комментарий, кажется это правильное объяснение. Т.е. дело именно в семантике, мы не хотим чтобы UseCase зависел от чего-то, что относится к инфраструктуре. Другие объяснения, что это инверсия зависимостей, а инверсия всегда хорошо, кажутся притянутыми за уши.
Вы привели общее описание Loose coupling. С таким же успехом можно было инвертировать вообще все зависимости на этой схеме, а чё б и нет, столько гибкости! Но почему-то между Presenter и Interactor этого нет, а между Interactor и Repository есть. Видимо преследуется какая-то неочевидная выгода. Опять же, судя по коду (пример выше), который часто приводят под Clean Architecture, сами же авторы не сильно заморачиваются с инверсией на этом участке.
Спасибо, а зачем это делается? Какую проблему мы пытаемся решить, когда инвертируем зависимость между
InteractorиRepository? Ведь направление запроса данных обратное от того, что нарисовано. Вот еще один пример на ту же тему: https://engineering.21buttons.com/clean-architecture-in-django-d326a4ab86a9. Судя по имплементации,Interactorпросто используетRepository, получает его в конструкторе. Но это не соответсвует тому, что нарисовано. По хорошему, он должен был инвертировать зависимость, как вы описали выше. Но… зачем?Я не уверен, что LiaminRoman получил ответ на вопрос. Точно так же привык, что
UseCaseтянет данные изRepository(или нескольких), добавляет нужную логику и передает выше. Но тогда направление на диаграмме было бы другим. Как конкретно Вы это реализуете, чтобы Repository был слоем выше, чемUseCaseи главное зачем это делать, если в статье четко написано, тоUseCaseближе кPresenter'ам? Почему просто не построить цепочкуPresenter --> UseCase --> Repository?Гм, так вот почему у меня нет девушки.