Архитектура. SOLID [RU] / Мобильный разработчик

Всем привет. Этим видео я открываю новую тему, а именно архитектуру мобильных приложений. Часть будет показано для примере на андроиде, часть на iOS. И первое видео посвящено, наверное, самым важным принципам, а именно принципам SOLID.
Ставь лайк и расскажи друзьям, чтобы они тоже узнали об архитектуре :)
Мобильный разработчик в других соц. сетях
=======================
Вконтакте - mdeveloper
Instagram - / nplau
=======================
Наши друзья и информационные партнеры:
t.me/androidev - Телеграмм канал, посвященный разработке для Андроид!
loftblog - Блок о разработке приложений и не только
Стать Патроном канала и получить доступ к уникальному материалу
/ mobiledeveloper
Поддержать канал рублем:
PayPal - [e-mail]
Mastercard - 5536 9137 9985 0652
Ставь лайк, подписывайся и пиши, чтобы ты хотел увидеть в следующих видео.

[@StBrother42]

Словами не передать, насколько качественный и нужный контент на канале. Спасибо тебе большое.

[@MobileDeveloper]

Спасибо большое, рад что понравилось! )

[@AntonParonko]

"Ссылка на активити - это вообще жопа" Заржал в голос :D

[@MobileDeveloper]

)))

[@user-jg4pk6bq2g]

Как тогда получить доступ к UI элементам из другого класса?

[@MobileDeveloper]

В смысле? Можно конкретнее?)

[@user-jg4pk6bq2g]

@@MobileDeveloper Я имею в виду, например, в неком классе мне нужно получить текст с EditText и произвести с ним некие манипуляции. Как это сделать без activity context?

[@MobileDeveloper]

А зачем вам тут контекст? У текстфилда есть text поле берёте его и кидаете в ваш класс

[@IvanPavlovYT]

Тайм-коды по расшифровке аббревиатуры: 3:05 S - Single Responsobility 4:17 O - Open-Closed Principle 5:48 L - Liskov Substitution Principle 8:28 I - Interface Segregation Principle 10:11 D - Dependency Inversion Principle

[@alexralex8877]

супер, все с примерами, "а теперь представим, что пришел менеджер и сказал ..." - так гораздо более понятен profit от хорошей архитектуры, примеры того, как не надо делать, тоже в тему, было бы здорово отдельно посмотреть про типичные анти-паттерны (GodClass уже был в видео, магические числа тоже, хочется еще) спасибо!

[@MobileDeveloper]

Спасибо! ) Да это будет в будущих видео по этой теме.

[@user-re6ru9br4l]

Никогда никому на ютубе ни на кого не подписывался и уж тем более не стваил "колокольчик". Тут Алексей может даже не просить об этом. Видео просто супер. Возможно не совсем для новичков, но подход и подача просто вышка! Готовлюсь к собеседованиям на джуна - Алексей очень помогает раскидать всё по полочкам. Почему бесплатно? (это не по русски и непривычно! ахаха)

[@MobileDeveloper]

Спасибо большое ) бесплатно просто так, потому что хочу развития технологий у нас в стране. Но есть и платный контент он лежит на патреоне.

[@it-6411]

По поводу удорожания разработки согласен на все 100: на работе постоянно говорили, что надо быстро и тд, но зато потом: Макс, добавь сюда это, туда то и туда то, естественно добавление всего нового функционала быстро и безболезненно, и все довольны)

[@MobileDeveloper]

Да, я тоже такой тактики придерживаюсь. Лучше потратить доп. время на архитектуру, чем потом страдать в постоянном продакшне)

[@it-6411]

От адаптера 1200 строк чуть сердечко не ёкнуло..

[@MobileDeveloper]

Хех, ну сейчас у меня такого нет уже ) Хотя там была очень очень сложная задача ) (это так немного в оправдание)

[@segreiulanov6057]

@@MobileDeveloper а вы не используете библиотеки для adapter типа BRVAH? Он мне кажется самым простым и удобным.

[@MobileDeveloper]

@@segreiulanov6057 нет стараюсь не тащить в проект библиотеки, если можно обойтись без них )

[@deadchannal]

Спасибо! Очень интересно! Жду новых выпусков про Архитектуру

[@MobileDeveloper]

А что еще можно рассказать?

[@deadchannal]

@@MobileDeveloper Если честно хотелось бы больше примеро в SOLID ичистой архитектуры в Андроид SOLID

[@MobileDeveloper]

Хм, да возможно стоит сделать отдельный выпуск про чистую архитектуру

[@deadchannal]

@@MobileDeveloper спасибо :)

[@preenxus3425]

1:13 S - Single Responsibility же

[@MobileDeveloper]

Блин )) действительно ) оговорился, видимо в голове крутилось object oriented ))

[@preenxus3425]

ооо, самое интересное начинается, усаживаемся поудобнее :)

[@MobileDeveloper]

Хаха, рад что зашло )

[@alexandernifanin7366]

Спасибо! Давно ждал. Понравились ваши примеры из реальных проектов. Почти нет лозунгов, которые очень отталкивают, когда смотришь чужие презентации, статьи про архитектуру. Обычно приводят какие-то преимущества, которые скорее недостатки. В этом смысле вы аккуратны, не пропагандируете подходы, а лишь говорите, что с ними может быть лучше. Вообще все эти методологии помогают при определённых условиях. Раньше использовал Clean, MVP, сейчас вернулся на MVC и особо не жалею. Будем ждать новых серий.

[@MobileDeveloper]

Спасибо большое! ) Да мне вот это вот все на VIPER тоже не очень нравится) потом смотришь на проект где два вьюконтроллера зато все на вайпер написано. Согласен, условия должны быть подходящими

[@alexandernifanin7366]

@@MobileDeveloper Да, я с вами полностью согласен! Забыл написать, что в случае с ArrayList не всё так однозначно. Я раньше тоже везде передавал List, но в последнее время также стал и ArrayList, MutableList (для адаптеров и операции addAll). Дело в том, что метод putParcelableArrayList требует исключительно ArrayList. Но я с вами согласен, если это возможно, лучше передавать родительский класс или интерфейс.

[@MobileDeveloper]

Alexander Nifanin тоже столкнулся с этой проблемой в parcelable )не знаю зачем они так сделали ) у меня есть отдельная функция которая берет на вход лист в любом формате и parcelable плюс ключ и возвращает parcel с уже вложенным массивом ) пришлось так сделать специально для этого случая

[@alexandernifanin7366]

@@MobileDeveloper Интересный способ. А вы лист преобразуете в массив?

[@MobileDeveloper]

@@alexandernifanin7366 неправильно выразился) я лист привожу к ArrayList )

[@Sakhalinec]

Познавательно! Было бы здорово увидеть серию уроков с реализацией какого нибудь приложения с нуля... например интернет магазин или вроде того...

[@MobileDeveloper]

Вроде делали вк ) но я вижу интерес не угасает ) окей подумаю об этом )

[@Sakhalinec]

Mobile Developer да я его видел. Я имел ввиду серию обучающих видео, где было бы максимальное приближение к реальным проектам... с объяснением всех этапов разработки от и до... у вас хорошие уроки, плюс такой серии уроков в том, что бы вы на практике показывали где и как юзать разные инструменты. Пиши с телефона, что не очень удобно! Надеюсь я смог до вас донести основную идею.

[@MobileDeveloper]

Понял да идею )) подумаю ) в моих планах это делать на стримах и вебинарах

[@preenxus3425]

32:40 есть небольшое замечание: скрывайте пожалуйста эту менюшку снизу, закрывает много кода.

[@MobileDeveloper]

Окей, со временем возьму нормальный монитор и увеличу разрешение )

[@alekseichemyakin2156]

Спасибо, отличное объяснение

[@MobileDeveloper]

Рад, что получилось объяснить )

[@Andrey-pu1lv]

Лучшее что есть на русском ютубе по данной теме, жду следующих видео! Автору успехов!

[@MobileDeveloper]

Спасибо большое ) сейчас вернусь из отпуска и начну новый сезон так сказать )

[@Andrey-pu1lv]

Mobile Developer, меня взяли стажером!) во многом благодаря этим видео!

[@MobileDeveloper]

Это очень круто )) значит не зря я их делаю )

[@romankryvolapov7961]

У каждого бывает, смотришь старые коды и думаешь- что это вообще такое... Хорошее видео, наверное архитектура- одно из самых важных на начальном этапе Тестировать нужно на старом устройстве

[@MobileDeveloper]

Согласен))) Постоянно такое у себя вижу)

[@romankryvolapov7961]

@@MobileDeveloper miro.medium.com/max/1400/1*NT1um6PYhJU4q9E26cQUew.png

[@MobileDeveloper]

@@romankryvolapov7961 хахах) да моя любимая шутка :))

[@romankryvolapov7961]

@@MobileDeveloper это отсюда medium.com/mindorks/understanding-clean-code-in-android-ebe42ad89a99

[@homie2417]

Я ржал с "тут нажали и тут же обработаем"))))

[@andyrumpel8641]

Годноту подвезли

[@MobileDeveloper]

Спасибо! ))

[@preenxus3425]

Расскажете про Интекрактор и Репозиторий? Очень запутанные сущности и все их понимают по-разному. Взять 100 проектов и везде связка Вью, Презентер, Интерактор, Репозиторий реализован по-разному. Очень хотелось бы посмотреть как это правильно сделать. Слышал, что Репозиторий надо инжектить, у него не должно быть ссылок на Презентер. Еще Презентер ведь просто посредник между вью и модел, но нет, кто-то там умудряется что-то обрабатывать. Вообщем куча вопросов. Ждем видео :)

[@MobileDeveloper]

Про это подробнее буду рассказывать в чистой архитектуре.

[@it-6411]

Специально даже запуллил с репозитория рабочий проект и поменял одно очень часто используемое int свойство на String, но в контексте моего проекта это сработает, так как неинтовых значений не будет))

[@MobileDeveloper]

Ну да, а попробуйте поменять String на Enum

[@Jocontacter]

Самый удобный для понимания пример по принципу L - это класс квадрата наследующийся от класса прямоугольника и замещающий реализацию сеттеров Width и Height так, чтобы при изменении Height, Width автоматически заменяется на то-же значение и наоборот. Для будущего пользователя будет сюрпризом такое поведение объекта приведенного к общему типу Rectangle. Для себя тогда сделал вывод, что в данном конкретном примере вообще не требуется такой класс как Square, т.к. это частный случай Rectangle. Поправьте, если я ошибаюсь в правильности способа как разруливать такую ситуацию.

[@MobileDeveloper]

В целом, принцип L по сути говорит нам о том, что при подстановке классов в переопределениях методах не должно быть какого-то поведения, которого ты не ожидаешь, поэтому если вы переопределяете метод setHeight и делает там ещё и setWidth это нарушение да, хотя особых проблем это вам не даст в этом случае, разве что лишние операции проверки при приведении к типу так как квадрат частный случай прямоугольника. А вот если вы просто сделаете новый метод у квадрата который сразу будет сетать сторону то с точки зрения архитектуры все норм )

[@schnaps1981]

хорошо! но для совсем младенцев, может посоветуешь что-то почитать об архитектуре? Или покажешь простенький пример, как проектировать приложение, так сказать от идеи до кода ) а то сейчас смотрю свои аппы, а они похожи на то, где в адаптере 1200 строк )))))

[@MobileDeveloper]

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

[@schnaps1981]

​@@MobileDeveloper "они всем известны" вот не всем )))) Если я буду говорить о себе, то в "высокое" программирование я погрузился где то с полгода назад, до этого 15 лет занимался программированием контроллеров, там несколько другая песня, а точнее больше плясок с бубнами ))) Тем не менее, читаю, изучаю... хорошо, что есть стековерфлоу и гитхаб))) но чем больше изучаю, тем сильнее понимаю, что я ничерта не знаю ((( тем не менее за полгода успешно зарелизил 3 приложения а сторе, первое время, только и занимался, что изучал стектрейс в крашлитикс )) Хочется плавать глубже, но как это сделать, если толком на поверхности плавать не умеешь... алгоритмы, структуры данных - это не проблема, проблема в том, что хочется делать красиво и быстро, как взрослые бородатые дяди )) буду благодарен, если получу пинка в направлении "что такое" паттерны и где их брать ))) Взамен на вебинар могу что-то полезное сделать для канала, а если будешь в Томске, то могу угостить самодельным пивасом ;) да и без вебинара могу )))))

[@MobileDeveloper]

Напиши плз мне в вк ) есть интересное предложение. Насчёт того с чего начать - я, наверное, выпущу отдельный ролик на эту тему, так как очень много запросов на тему с чего начать

[@schnaps1981]

@@MobileDeveloper окей, написал

[@preenxus3425]

25:07 у вас все адаптеры лежат в папке adapters и к сущности (классу) дописывается просто слово Adapter. А если это будет не для ресайклера адаптер, а для ViewPager, например?

[@MobileDeveloper]

Там все адаптеры лежат и для VP тоже

[@preenxus3425]

@@MobileDeveloper а как вы по названию определяете какой из них вьюпейджер? Они все Adapter называются. И отсюда неаонятно какой из них ресайклер, а какой вьюпейджер

[@MobileDeveloper]

Я их называю PagerAdapter

[@alekseimakarov3531]

Какие Open Source проекты ты советуешь поизучать,?

[@MobileDeveloper]

Android Architecture examples github.com/android/architecture-samples

[@segreiulanov6057]

Я предпочитаю использовать mvp, пробовал mvvp, но он мне показался слишком сложным из-за кодогенерации, как-бы даррег второй, этот mvvp. А вот на счёт циклов, я некогда не использовал их в других потоках, но вы сказали их лучше использовать в другом потоке? А ещё, почему так ArrayList плох?

[@MobileDeveloper]

Не совсем понял, а mvvp - это что? Или вы имели ввиду MVVM? Ну если цикл очень ресурсоемкий (а редко бывает иначе), то конечно его не надо крутить в главном потоке )) Сильный телефон это переварит, а вот слабый нет. Я не говорил что ArrayList - плох ) Я говорю, что по максимуму надо не конкретизировать левую часть присваивания, чтобы пользоваться такой чудесной штукой как полиморфизм

[@segreiulanov6057]

@@MobileDeveloper да, я про mvvm) А как именно конкретизировать? Чёт не очень понял.

[@MobileDeveloper]

Ну если вы в функцию передаёте аргумент ArrayList вы не сможете воспользоваться этой функцией если у вас LinkedList или своя реализация. А если у вас List то пожалуйста - передавайте какую хотите. То есть по возможности нужно абстрагироваться от реализации. Но тоже главное без фанатизма

[@segreiulanov6057]

@@MobileDeveloper интересная мысль, не сталкивался, но уже хочу проверить)) Спасибо

[@MobileDeveloper]

Всегда пожалуйста )

[@FoRGeish]

13:58 Вот, кстати тоже часто путаница в понятиях связанность и зацепление. Все-таки, сильная связанность - это хорошо, плохо - сильное зацепление. Не так ли?))

[@MobileDeveloper]

Хм, а как вы видите разницу между понятиями связанность и зацепление? Просто я про зацепление слышал один раз, но в целом везде употребляется связность, даже в той самой книге про архитектуру.

[@FoRGeish]

@@MobileDeveloper www.geeksforgeeks.org/software-engineering-coupling-and-cohesion/ Wiki переводит их как: ru.m.wikipedia.org/wiki/%D0%A1%D0%B2%D1%8F%D0%B7%D0%BD%D0%BE%D1%81%D1%82%D1%8C_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5) и ru.m.wikipedia.org/wiki/%D0%97%D0%B0%D1%86%D0%B5%D0%BF%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)

[@Sakhalinec]

👍 👍 👍 👍 👍

[@MobileDeveloper]

Спасибо ))

[@igorpi25]

10:55 в теории - нет, на практике - обязательно. Ребрендинг должен затрагивать только стили, по идее, но в реальности оно затронет все, включая бэкенд, и провайдеров oAuth. Solid - хорош для промышленного софта, где код работает десятилетиями, но не для приложений бизнес уровня, где требования меняются каждый месяц

[@MobileDeveloper]

Мы спокойно провели небольшой ребрендинг, затронув, только дизайн систему фактически. Так что есть вещи, которые не меняются годами и в бизнес приложениях )

[@momentslikethis8014]

почему ты юзаешь дагер с котлином , а не Kodein?

[@MobileDeveloper]

Основная причина потому что даггер меня всем устраивает. А так я посмотрел Кодеин работает в рантайме и можно runtime exception словить - это не очень надежно, а даггер позволяет все отловить на стадии компиляции.

[@mrtwon8638]

Вы полностью на kotlin перешли ? Или на java все же есть проекты

[@MobileDeveloper]

Нет, я давно уже на котлине только

[@it-6411]

Зависимости: привет MV* паттерны: ui и навигация от бизнес-логики, работающей с бд и сервером)

[@MobileDeveloper]

Я не понял, это плохо?)

[@it-6411]

Из int в String: самое первое, что пришло в голову, это в геттере возвращать Integer.parseInt(), но встаёт проблема, что делать, если в параметре будет "unknown", возвращать какое-то другое значение, потом проверять, ну это уже костыль)

[@MobileDeveloper]

Тут, имхо, только конвертеры между слоями помогут.

[@Jocontacter]

@@MobileDeveloper Чем плохо оставить int? Unknown - это ui-интерпретация нуля. Работы по-минимуму, все решается легкой модификацией ui-слоя. В БД так собственно и принято - если id=0 то insert, если >0 - то update. И нормально все себя чувствуют.

[@MobileDeveloper]

Я уже плохо помню контекст, но там смысл был в другом )

[@preenxus3425]

16:31 не butterknife ли выпиливали?))

[@MobileDeveloper]

Нет я им не пользуюсь, это databinding

[@it-6411]

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

[@MobileDeveloper]

Это где?)

[@user-fb7do4nc6r]

Спасибо тебе автор за то что ты это делаешь

[@MobileDeveloper]

Рад помочь ))

[@alex5381]

17:50 Как эти менеджеры работают если не понимают предметную область? Или это больше безответственность?

[@MobileDeveloper]

Ну других то нет ))

[@picgo8416]

28:30 :))

[@MobileDeveloper]

Бурная молодость )

[@alex5381]

16:50 Эти студии-галеры с текучкой кадров и отвратительным качеством кода могут делать только одноразовые мелкие проекты? И давать им большие или средние проекты с большей стоимостью нельзя? За счет чего они живут если так отвратительно работают?

[@MobileDeveloper]

Нет, они часто делают долгие проекты и очень большие. А держится это все на повальной не компетентности принимающей стороны

[@immortal_lnight]

Я Джуниор. Когда я вижу ТАКИЕ проекты я психологически умираю. Дайте успокоительное.. пожалуйста...

[@momentslikethis8014]

MVP\MVVM очень жду потмоу что пользуюсь и хочу увидеть что где не так

[@MobileDeveloper]

Дойду и до этого )

[@user-xl2tf4gq1g]

ждем!

[@sexol1235]

а если человек забудет отсканировать время?)

[@MobileDeveloper]

А можете таймметку дать?)

[@igorpi25]

17:47 все-равно архитектура окажется неподходящей на будущие требования, все что угодно сделай, все равно будет убогое неуклюжее. Надо вытащить наган из кармана и застрелить лошадь на месте где упала. Рефакторить новую ровно на текущие задачи чтобы хватило, и жить спокойно. Требования поменяются поменяем архитектуру. И таким образом будет наслаиваться и "калиться" настоящая структура и форма проекта расчитанная для поля боя

[@MobileDeveloper]

Тут я вижу не двойственную картину мира, а некий range. Вполне можно предвидеть тот факт, что формы станут сложнее, запросов будет все больше и тд и тп) иначе архитектур бы не существовало. Но) предвидеть переход с реста на сокеты довольно тяжело и непонятно зачем, поэтому делать абстракцию над сетевым слоем с этой целью уже не очень попятно зачем. Поэтому я бы сказал рефакторить нужно ровно столько сколько надо плюс примерно на год другой вперёд )

[@igorpi25]

12:15 по идее - нет, но все же будет - да. Наверное, потребуется добавить новое свойство в пользователе, которого небыло изначально, типа telegram-id и весь pipline на всех семидесяти семи слоях нужно будет рефакторить. Это же модно, попробуй сказать весь ваш солид гавно, тебя обвинят в гомофобии, расизме, алкоголизме, непрофессионализме, неполиткорректности и т. д. и попытаются избавиться

[@MobileDeveloper]

Хахах )) да, кстати, если оно будет добавлено на сервере это нужно будет прокинуть до верхнего слоя, однако! Мы не раз сталкивались с тем, что нам удавалось решать проблему замкнувшись внутри одного слоя абстракции, например, когда поле служебное и не нужно для отображения. Так что смысл в этом есть, главное, как и везде, без фанатизма. А насчёт солида, опять же сами принципы говном быть не могут ) а вот применить их хреново можно и ещё как ))

[@igorpi25]

@@MobileDeveloper безусловно solid правильный принцип для проектирования отдельно взятых сущностей и их локальных связей. Однако эти принципы слишком примитивны, чтобы описать природу взаимодействий между целыми слоями архитектуры. Именно из-за попытки применить mvvm, mvp, mvc буквально возникает ужасы. Раньше все строили архитектуру, которая больше отвечает этим принципам, чем сейчас когда принципы объявили новой религией и воздвигли им церковь. Столько пустой работы и разговопов, столько гордыни, все посходили с ума. У безталантливых программистов появилось оружие БИБЛИЯ. Теперь нельзя ссылаться на простой здравый смысл и целесообразность. Инквиторы, чертовы, тебе прочитают очередную аббревиатуру из книги. Год писал на vue, node, graphql. Одно удовольствие. Вот опять возвращаюсь к проклятому Android, наполненному пафосом и идиотизмом. Привет орда узколобых фанатиков! Хехей! Я снова дома

[@alex5381]

14:50 У моего друга на работе в продуктовой компании эффективный менеджер так и поступил. Был отдел отвечавший за мобильное приложение. Чтобы сэкономить отдали мобильную часть на аутсорс. Как быстро это скажется на качестве продукта? Поймет ли менеджер что совершил ошибку? Или экономия с точки зрения менеджера будет предпочтительнее чем потеря качества? Может менеджмент посчитал что приложение полностью готово и дальнейшие изменения будут требоваться очень редко и для этого не надо содержать своих мобильных разрабов? Почему в этой ситуации просто не провели сокращение в мобильном отделе? Зачем уничтожать отдел теряя контроль над разработчиками? С деньгами в компании все очень хорошо, просто нужно было сэкономить и тем самым повысить прибыль.

[@MobileDeveloper]

Менеджеру нужно было выполнять свои KPI и он их выполнил. Вообще выстраивание эффективной модели в компании это тема отдельных научных работ) Потому что любую систему будут пытаться взломать)

[@dmitriyobidin6049]

14:20 Плохая система монолитна - зачастую да. Но не надо автоматом применять это правило в обратную сторону, не каждый монолит - плохая архитектура.

[@MobileDeveloper]

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

[@dmitriyobidin6049]

@@MobileDeveloper Ну от этого есть польза, только уже многие на практике пришли к выводу, что на старте проекта когда над ним работает одна команда - хорошо спроектированный монолит выгодней. Микросервисы же это скорее дальнейший(возможный) этап развития монолита, нежели его прямая альтернатива. Иногда же люди гонятся за модой и стартуют сразу с микросервисом, т.к. "монолит - зло". Почему-то у некоторых монолитная архитектура ассоциируется с "водопадом", хотя она и в agile подходе нормально живет :)

[@MobileDeveloper]

Это как говорить что молоток плохой. Молоток это инструмент. А уж как его использовать задача мастера