Pull to refresh
44.2
Karma
0
Rating
Василий Чирвон @Jeevuz

Android Developer

  • Followers 33
  • Following

Навигация с архитектурными компонентами от Google. Часть 1. Знакомство

Хорошая вводная статья, спасибо! Понравилось, что сперва перечислены требования к навигации.

Реактивные приложения с паттерном RxPM. Прощайте​ MVP и MVVM

Да? А по ссылочке перейти и прочитать:


Then use Avalon's data binding functionality to declaratively (in the XAML) wire the View to the ViewState and/or directly to the Model.

На Википедию тоже не будет лишним сослаться (https://ru.wikipedia.org/wiki/Model-View-ViewModel):


Первоначально был представлен сообществу Джоном Госсманом (John Gossman) в 2005 году как модификация шаблона Presentation Model

В общем, вопрос считаю закрытым. Поддерживать диалог дальше не стану, прошу меня простить.

Реактивные приложения с паттерном 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

Для полей View из Kotlin Android Extension используется стиль именования lower_snake_case

Печаль.

Пулл-реквесты с эмпатией

Можно быть в курсе задачи, которую ты делаешь, но не быть в курсе возникших проблем и причин почему выбрано то или иное решение.


В практике бывало такое, ревьюишь кого-то, пишешь мол зачем ты тут эту дрянь сделал, в ответ на что узнаешь, что это из-за кучи проблем и невозможности использовать другое более хорошее решение (которое было проверено). Не пришлось бы задавать эти вопросы будь это описано сразу в пиаре.

Заблуждения 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 по определению:


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.

Просто скидка что-то очень общее. То что вряд ли будет меняться часто. И не будет зависеть от того надо ли показывать ее с бонусами или без скидки цену выводить и тп.


И опять же:


прямо в классе печеньки

Не обязательно в классе печеньки это делать. Даже я бы сказал не стоит может. Вдруг это работает и на печеньки и на конфетки. Это уже деталь реализации, так можно, но хочу заострить внимание, что это не обязательно так.

Заблуждения Clean Architecture

Будет Entity. Потому что это логика общая для всего бизнеса, а не только для приложения.

Заблуждения Clean Architecture

Не согласен с приведенной формулой. Entity не обязано иметь список полей.
Оно может быть просто функцией, может быть объектом наследующим тот у которого нужные поля, может принимать этот объект на вход метода, может просто принимать все поля на вход метода.


Entity также вполне может работать с несколькими объектами и использовать их поля для выполнения свой функиции. Ведь Entity это логика, метод, функция.


логики обединения description из разных Entity

Эта фраза подразумевает, что Entity объект. С чем я не согласен, как уже сказал.
Это не обязательно. А когда Entity не объект, то такая логика может быть в Entity, а не в интеракторе. Интерактор возьмет Entity, даст ей список разных description и Entity сделает что нужно с ними.


Интерактор же может потом еще другую логику из другой Entity применить или логику, которая не от бизнеса, а специфичная для приложения.

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Registered
Activity