💎 Клиентская архитектура

"если все, что у вас есть, это молоток, все выглядит как гвоздь"

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

Как организовать инфраструктуру приложения?
Ответов на этот вопрос множество. Пройдемся по нескольким вкратце и возьмем не только мобильные приложения. И почти не затронем iOS.

CLEAN — одна из основных концепций разделения логики тестируемым и гибким способом.

FSD (Feature Sliced Design) — Основная цель этой методологии - сделать проект более понятным и структурированным в условиях постоянно меняющихся бизнес-требований за счет нарезки на отрезки и четкой структуры

BLoC (Business Logic Component) — разрабы флаттера придумали свою архитектуру для разделения бизнес логики от интерфейса

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

- Основы клиентской архитектуры
- Vertical Slice Architecture
- DDD на практике

🤳🤳🤳🤳🔥

Лучший ютуб канал про иос разработку на днях сделал хороший пример про тестируемость и гибкость хорошей архитектуры. 5 минут полезней двух сезонов подлодки

Еще крутейшие видосы с канала:
- использование инкапсуляции в проекте
- решение реальных проблем с помощью Single Responsobility
- Почему модуляризация — это решение бизнес-логики
- майндсеты для архитекторов под ios

☁️ прикольный тред чела, который готовился на собесы систем дизайна в западные компании

Опять же: проектирование — это знание системы на всех уровнях. Начиная от знания сети и бэка, заканчивая платформы и бизнес логики

https://twitter.com/e_matsyuk/status/1519539090097643521?s=20&t=DDEe04Mi8X3wONvKVd4hCw

🥱 MVC == MVP

🍏 MVC

Большое заблуждение в индустрии, что View и Controller связаны в одну сущность — ViewController. Но это не так. В своей документации эйпл говорила о комбинирующих ролях. Такое объединение допустимо лишь для некоторых апок, но не для всех.

Но если Controller != ViewController, и роль Presentor выполняет Controller, то чем тогда MVC отличается от MVP?

Фаулер описал это еще в далеком 2006 году для GUI архитектур. Еще тогда он описал о проблеме толковании MVC паттерна:

☁️ Разные люди, читающие о MVC в разных местах, берут из него разные идеи и описывают их как «MVC». Если это не вызывает достаточной путаницы, вы получаете эффект непонимания MVC, который развивается через систему китайского шепота.

Вся суть и история МVC — это в Separeted Presentation, где выделяется логика предметной области и вьюхами.

🍏 MVP
Шаблон проектирования MVP необходим уже тогда, когда ваше приложение имеет множество View.

Если просто, то основное отличие, это в том, что презентор должен ссылаться на вью. Когда в каноничном MVC — Controller не знает о вью.

💎 Но только не в иос. У нас MVC от эйпла одно и то же, что и MVP. Но многие придумали себе несуществующих проблем и сделали VIPER

- Дока эйпла по MVC
- Разница между MVC vs MVP
- Мартин Фаулер и GUI архитектуры

Подборка лучших дизайн паттернов для iOS 🤡

Лидирует MVC, observer, command и билдер:

- норм репо с примерами

- Топ паттернов за 2022

- легкое объяснение самых частых паттернов

- доп. Материал с паттернами

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

Одна из супер главный вещей для прогера — музыка. Она создает ритм и фон работе. Теперь будем собирать плейлисты для эффективной работы в такой сложной науке как кнопкостроение.

Начну с себя. Хоть я нихера не музыкант и не смогу описать собранный жанр, но попробую описать сердцем.

Собранные мной звуки электронной музыки бьют нотами индустриализации и модерна.

Здесь смешалось всё. Симфонии фиксов багов. Танец битов и байтов. Скачки напряжение и толчки бассов фокусят на тональность дедлайна. Где-то музыка давит тяжестью толстых реквестов. Где-то окрыляет быстрой сборкой.

🎹 плейлист: https://music.yandex.ru/users/levbond93/playlists/1013

Single Responsibility Principle

В "Чистой архитектуре" Мартин говорит:

Принцип единственной ответственности касается функций и классов, но он проявляется в разных формах на еще двух более высоких уровнях:

На уровне компонентов он превращается в принцип согласованного изменения

💎

Принцип согласованного изменения — в один компонент должны включаться классы, изменяющиеся по одним причинам и в одно время. В разные компоненты должны включаться классы, изменяющиеся в разное время и по разным причинам. По сути это перефразированный SRP, только для компонентов. Иначе говоря, компонент не должен иметь несколько причин для изменений.

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

Сходство с принципом единственной ответственности:

Принцип SRP требует выделять методы в разные классы, если они изменяются по разным причинам.
Принцип CCP аналогично требует выделять классы в разные компоненты, если они изменяются по разным причинам. Оба принципа можно привести к общей формуле:

Собирайте вместе все, что изменяется по одной причине и в одно время. Разделяйте все, что изменяется в разное время и по разным причинам.

- Common Closure Principle

Component cohesion (Связанность компонентов)

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

Архитектор, уделяющий внимание только принципам REP и CRP, обнаружит, что простое изменение вовлекает слишком большое количество компонентов . С другой стороны, архитектор, уделяющий особое внимание принципам CCP и REP, вынужден будет выпускать слишком много ненужных версий.

⚖️ Хороший архитектор найдет в этом треугольнике противоречий золотую середину, отвечающую текущим нуждам разработчиков, а также подумает об изменениях, которые могут произойти в будущем . Например, на ранних этапах разработки проекта принцип CCP намного важнее, чем REP, удобство разработки важнее удобства повторного использования.

- Component cohesion: principles and benefits
- 3 правила связанности для джуна