Декомпозиция программных компонент

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

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

? Обратите внимание, что далее стрелки показывают не движение данных, как их часто рисуют, а наличие знания одного компонента системы, как работать с другим. В пределе это знание выражается в полном контроле жизненного цикла: от создания, до уничтожения. Отсутствие же знания даёт независимость от конкретной реализации, а значит и возможность работать с разными реализациями.

Model-View

Модель знает как себя по разному представлять.

Пример

class User { // Model  _id: bigint _nickname: string  toString() { // View return 'user=' + this._id }  toJSON() { // View return { id: String( this._id ), name: this._nickname, } }  }

Особенности

✅ Удобно из модели получать любые отображения.

❌ Добавление нового отображения требует изменения модели.

❌ Отображение полностью определяется одной основной моделью.

❌ Загрузка модели вытягивает по зависимостям и все её отображения.

❌ Двух слоёв слишком мало на больших масштабах.

View-Model

Код работы с моделями пишется прямо в отображении.

Пример

// View function Task_list() { return <ul>{ Task.list.map( task => <li><Task_row {task} /></li> ) }</ul> }  // Model class Task { static list = [] as Task[] }

Особенности

✅ Отображение может использовать произвольные модели.

✅ Легко добавлять новые отображения, не меняя модели.

❌ Для отображения разных моделей необходимо дублировать код отображения.

❌ Изменение интерфейса модели требует обновления всех использующих её отображений.

❌ Двух слоёв слишком мало на больших масштабах.

Model-View-ViewModel

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

Пример

// View <li class="User_card" model="User_card_model"> <img src={ image } /> <p>{ message }</p> </li>  // ViewModel class User_card_model { user = User.current get image() { return this.user.avatar } get message() { return this.user.nickname } }  // Model class User { avatar: string nickname: string static current = new User }

Особенности

✅ Отображение может использовать произвольные вьюмодели.

✅ Легко добавлять новые отображения, не меняя ни модели, ни вьюмодели.

✅ Изменение интерфейса модели или отображения требует изменения только лишь вьюмодели.

✅ Одну и ту же вьюмодель можно шарить между несколькими отображениями.

❌ Для отображения разных моделей необходимо дублировать код отображения и вьюмодели.

❌ Трёх слоёв слишком мало на больших масштабах.

Model-View-Controller

Контроллер создаёт отображение, и говорит ему с какой моделью работать. Так же он обрабатывает все команды от пользователя, и управляет своими подопечными.

Пример

// Controller class Users_resource { GET() { return User.all.map( user_brief ) } }  // View function user_brief( user: User ) { return { id: user.guid, name: user.passport.name_full, } }  // Model class User {  static all = [] as User[]  guid: GUID passports: Passport[] resumes: Resume[]  get passport() { return this.passports[0] }  }

Особенности

✅ Отображение может использовать произвольные модели с тем же интерфейсом.

✅ Легко добавлять новые отображения, не меняя модели. И наоборот.

❌ Для отображения разных типов моделей необходимо дублировать код отображения.

❌ Изменение интерфейса модели требует обновления всех использующих её отображений и контроллеров.

❌ Трёх слоёв слишком мало на больших масштабах.

Model-View-Presenter

Модели и отображения пассивны, и не знают друг о друге — они управляются презентером, который выступает и в качестве посредника между ними.

Пример

// Presenter class User_preview { user: User card = new Card({ image: ()=> this.user.avatar, message: ()=> this.user.nickname, color: ()=> this.user.skin.color, click: ()=> this.skin_change(), }) skin_change() { this.user.skin = Skin.random() } }  // View <div class="Card" onclick={click} style={{ background: color }}> <img src={ image } /> <p>{ message }</p> </div>  // Model class User extends Model { avatar: string nickname: string skin: Skin }

Особенности

✅ Легко добавлять новые отображения, не меняя модели. И наоборот.

✅ Изменение интерфесов модели или отображения требует изменения только лишь презентеров.

❌ Трёх слоёв слишком мало на больших масштабах.

❌ Для использования состояния одного презентера из другого необходимо искусственное вынесение его в модели.

ModelView Fractal

Каждый ModelView выступает в роли модели/контроллера для ведомых ModelView и в качестве отображения для владеющего ModelView. Часть логики может выноситься как в чистые Model, так и в чистые View, которые являются лишь вырожденными случаями ModelView.

Пример

$my_user_list $my_view - \Owner ModelView users? /$my_user kids / <= Row*0 $my_user_row user <= user* $my_user  $my_user_row $my_card - \Having ModevView user $my_user avatar => image nickname => message  $my_card $my_view - \View not Model kids / <= Image $my_image uri <= image \about:blank <= Message $my_text text <= message \  $my_user $my_model - \Model not View avatar? \ nickname? \

Особенности

✅ Каждый ModelView полностью контролирует внутренние ModelView и ничего не знает про внешние.

✅ Любой ModelView может шариться между разными другими ModelView на любом уровне композиции.

✅ Изменение интерфейса ModelView требует изменения только лишь его владельцев.

✅ Фрактальная структура легко масштабируется на приложения любого размера.

Выводы

$mol_view построен на идеях MVF, так как это наиболее простой паттерн декомпозиции, который легко масштабируется по мере потребности и хорошо разделяет разные уровни абстракции.

Ссылочки

Другие анализы
Следите за новостями
Обсуждайте наболевшее
Донатьте на печеньки

---

Актуальный оригинал на $hyoo_page.