Если вы реализуете автоматический(автоматизированный) биндинг, то получится по-сути фреймворк. Поэтому в вашем вопросе нет смысла. Тк из всего, что было написано ранее видно, что MVVM без автоматизированного датабиндинга это и есть PM.
Но видимо вы не читаете текст, а просто ищите поводы поспорить.
Я считаю абсолютно правильным то как сейчас сделано. То, что имена в файлах такие же как в xml.
И попробовав, считаю, что camelCase в лейаутах гораздо удобнее.
Можно быть в курсе задачи, которую ты делаешь, но не быть в курсе возникших проблем и причин почему выбрано то или иное решение.
В практике бывало такое, ревьюишь кого-то, пишешь мол зачем ты тут эту дрянь сделал, в ответ на что узнаешь, что это из-за кучи проблем и невозможности использовать другое более хорошее решение (которое было проверено). Не пришлось бы задавать эти вопросы будь это описано сразу в пиаре.
Хехе, я же даже жирным выделил "Dependency Rule говорит нам, что внутренние слои не должны зависеть от внешних". И весь раздел про Dependency Rule говорит об этом.
И дальше по тексту было, что dependency inversion principle используется чтобы этого добиться просто. ;)
Посмотрите на схему дяди боба, где нарисованы Boundaries, прочтите еще раз про передачу данных и потом снова скажите, что между Presenter и Interactor этого нет ;)
Заморачиваться или нет — выбор каждого.
Это же зависимость. А любая зависимость означает связь и изменения зависимого при изменениях того от кого зависят. Если Интерактор зависит напрямую от Репозитория, то при замене репозитория мы должны будем вносить изменения в Интерактор тоже.
Уменьшить такую связанность и дать больше гибкости для изменений — это и есть цель Dependency rule.
Кроме изменений, связность можно почувствовать подумав о работе командой. Представьте вы бы работали над логикой огромного Интерактора, а ваш коллега пока делал бы все репозитории. Вы бы зависели от того сделал ли он уже нужный репозиторий или нет. И что там сделал. А с интерфейсом, вы бы работали над своей логикой спокойно используя интерфейс. А когда там и кто реализует его вас не волновало бы.
Не совсем понял вопрос. Если вы о направлении зависимостей, то применяем принцип инверсии зависимостей. Т.е. в слое логики лежит интерфейс и Интерактор зависит от него. А репозиторий, находясь в другом слое реализует этот интерфейс, то есть зависит от него. Так зависимости направлены во внутрь от репозитория к слою UseCases.
Так это должно быть. А как на практике другой вопрос. На деле этот репозиторий может никогда не меняться и делать для него интерфейс может быть лишней затратой. То есть можно и не сделать его, но это будет компромисс с собой. Надо знать как правильно, ну а делать исходя из обстоятельств. Если вы уверены что подменять репозиторий целиком не придется, то в этом интерфейсе нет практической ценности. Как-то так.
Если нет бизнеса, и наше приложение само по себе, то скидка все равно может быть в Entity по определению:
If you don’t have an enterprise, and are just writing a single application, then these entities are the business objects of the application. They encapsulate the most general and high-level rules. They are the least likely to change when something external changes.
Просто скидка что-то очень общее. То что вряд ли будет меняться часто. И не будет зависеть от того надо ли показывать ее с бонусами или без скидки цену выводить и тп.
И опять же:
прямо в классе печеньки
Не обязательно в классе печеньки это делать. Даже я бы сказал не стоит может. Вдруг это работает и на печеньки и на конфетки. Это уже деталь реализации, так можно, но хочу заострить внимание, что это не обязательно так.
Не согласен с приведенной формулой. Entity не обязано иметь список полей.
Оно может быть просто функцией, может быть объектом наследующим тот у которого нужные поля, может принимать этот объект на вход метода, может просто принимать все поля на вход метода.
Entity также вполне может работать с несколькими объектами и использовать их поля для выполнения свой функиции. Ведь Entity это логика, метод, функция.
логики обединения description из разных Entity
Эта фраза подразумевает, что Entity объект. С чем я не согласен, как уже сказал.
Это не обязательно. А когда Entity не объект, то такая логика может быть в Entity, а не в интеракторе. Интерактор возьмет Entity, даст ей список разных description и Entity сделает что нужно с ними.
Интерактор же может потом еще другую логику из другой Entity применить или логику, которая не от бизнеса, а специфичная для приложения.
Навигация с архитектурными компонентами от Google. Часть 1. Знакомство
Хорошая вводная статья, спасибо! Понравилось, что сперва перечислены требования к навигации.
Реактивные приложения с паттерном RxPM. Прощайте MVP и MVVM
Да? А по ссылочке перейти и прочитать:
На Википедию тоже не будет лишним сослаться (https://ru.wikipedia.org/wiki/Model-View-ViewModel):
В общем, вопрос считаю закрытым. Поддерживать диалог дальше не стану, прошу меня простить.
Реактивные приложения с паттерном RxPM. Прощайте MVP и MVVM
Если вы реализуете автоматический(автоматизированный) биндинг, то получится по-сути фреймворк. Поэтому в вашем вопросе нет смысла. Тк из всего, что было написано ранее видно, что MVVM без автоматизированного датабиндинга это и есть PM.
Но видимо вы не читаете текст, а просто ищите поводы поспорить.
Реактивные приложения с паттерном RxPM. Прощайте MVP и MVVM
Согласен. Это не MVVM. Но речь и не шла о том, что это MVVM. Слова вырваны из контекста.
Kotlin code style
Я считаю абсолютно правильным то как сейчас сделано. То, что имена в файлах такие же как в xml.
И попробовав, считаю, что camelCase в лейаутах гораздо удобнее.
Kotlin code style
Как написал ниже yanex можно включить подсветку для них. А использовать в коде имена не по конвенции не очень хорошо.
Kotlin code style
Ну и стаилгайды в общем вкусовщина. Имхо, camelCase в xml меньшее зло. И так пишут те же гугловцы. Например, Reto Mayer в одном видео так писал.
Kotlin code style
Печаль.
Пулл-реквесты с эмпатией
Можно быть в курсе задачи, которую ты делаешь, но не быть в курсе возникших проблем и причин почему выбрано то или иное решение.
В практике бывало такое, ревьюишь кого-то, пишешь мол зачем ты тут эту дрянь сделал, в ответ на что узнаешь, что это из-за кучи проблем и невозможности использовать другое более хорошее решение (которое было проверено). Не пришлось бы задавать эти вопросы будь это описано сразу в пиаре.
Заблуждения Clean Architecture
Хехе, я же даже жирным выделил "Dependency Rule говорит нам, что внутренние слои не должны зависеть от внешних". И весь раздел про Dependency Rule говорит об этом.
И дальше по тексту было, что dependency inversion principle используется чтобы этого добиться просто. ;)
Заблуждения Clean Architecture
Посмотрите на схему дяди боба, где нарисованы Boundaries, прочтите еще раз про передачу данных и потом снова скажите, что между Presenter и Interactor этого нет ;)
Заморачиваться или нет — выбор каждого.
Заблуждения Clean Architecture
Это же зависимость. А любая зависимость означает связь и изменения зависимого при изменениях того от кого зависят. Если Интерактор зависит напрямую от Репозитория, то при замене репозитория мы должны будем вносить изменения в Интерактор тоже.
Уменьшить такую связанность и дать больше гибкости для изменений — это и есть цель Dependency rule.
Кроме изменений, связность можно почувствовать подумав о работе командой. Представьте вы бы работали над логикой огромного Интерактора, а ваш коллега пока делал бы все репозитории. Вы бы зависели от того сделал ли он уже нужный репозиторий или нет. И что там сделал. А с интерфейсом, вы бы работали над своей логикой спокойно используя интерфейс. А когда там и кто реализует его вас не волновало бы.
Заблуждения Clean Architecture
Не совсем понял вопрос. Если вы о направлении зависимостей, то применяем принцип инверсии зависимостей. Т.е. в слое логики лежит интерфейс и Интерактор зависит от него. А репозиторий, находясь в другом слое реализует этот интерфейс, то есть зависит от него. Так зависимости направлены во внутрь от репозитория к слою UseCases.
Так это должно быть. А как на практике другой вопрос. На деле этот репозиторий может никогда не меняться и делать для него интерфейс может быть лишней затратой. То есть можно и не сделать его, но это будет компромисс с собой. Надо знать как правильно, ну а делать исходя из обстоятельств. Если вы уверены что подменять репозиторий целиком не придется, то в этом интерфейсе нет практической ценности. Как-то так.
Заблуждения Clean Architecture
Ну так в том и смысл, что это будет структура данных. А логика может быть и отдельно.
Не вижу обязательности в совмещении.
Заблуждения Clean Architecture
Смешивать не проблема. Просто я говорю, что это не является обязательным.
Заблуждения Clean Architecture
А что в этом плохого?
Заблуждения Clean Architecture
Так и сделать сущность отдельную. А функция её примет. Зачем логике внутреннее состояние?
Не обязательно смешивать логику и сущность, я об этом.
Заблуждения Clean Architecture
Если нет бизнеса, и наше приложение само по себе, то скидка все равно может быть в Entity по определению:
Просто скидка что-то очень общее. То что вряд ли будет меняться часто. И не будет зависеть от того надо ли показывать ее с бонусами или без скидки цену выводить и тп.
И опять же:
Не обязательно в классе печеньки это делать. Даже я бы сказал не стоит может. Вдруг это работает и на печеньки и на конфетки. Это уже деталь реализации, так можно, но хочу заострить внимание, что это не обязательно так.
Заблуждения Clean Architecture
Будет Entity. Потому что это логика общая для всего бизнеса, а не только для приложения.
Заблуждения Clean Architecture
Не согласен с приведенной формулой. Entity не обязано иметь список полей.
Оно может быть просто функцией, может быть объектом наследующим тот у которого нужные поля, может принимать этот объект на вход метода, может просто принимать все поля на вход метода.
Entity также вполне может работать с несколькими объектами и использовать их поля для выполнения свой функиции. Ведь Entity это логика, метод, функция.
Эта фраза подразумевает, что Entity объект. С чем я не согласен, как уже сказал.
Это не обязательно. А когда Entity не объект, то такая логика может быть в Entity, а не в интеракторе. Интерактор возьмет Entity, даст ей список разных description и Entity сделает что нужно с ними.
Интерактор же может потом еще другую логику из другой Entity применить или логику, которая не от бизнеса, а специфичная для приложения.