JS

MV*

Agenda

Development WEB

Development CSS

Development JavaScript

SPA

Одностраничное приложение (single-page application, SPA) - это веб-приложение или веб-сайт, использующий единственный HTML-документ как оболочку для всех веб-страниц и организующий взаимодействие с пользователем через динамически подгружаемые HTML, CSS, JavaScript, обычно посредством AJAX. SPA напоминают родные (native) приложения, с той лишь разницей, что исполняются в рамках браузера, а не в собственном процессе операционной системы

Development quality js code

Development languages programming

Design patterns

Шаблоны проектирования - это повторяющиеся решения общих проблем в разработке программного обеспечения.

Design patterns (GOF)

Порождающие паттерны - предназначены для создания новых объектов в системе.
Структурные паттерны - решают задачи компоновки системы на основе классов и объектов (рассматривается вопрос о том, как из классов и объектов образуются более крупные структуры).
Паттерны поведения - предназначены для распределения обязанностей между объектами в системе.

Design Patterns Elements of Reusable Object-Oriented Software

Complexity of the system

сложностью предметной области;
трудностью управления разработкой программного обеспечения;
необходимостью обеспечить гибкость программ;

Layering

Концепция слоев (layers) — одна из общеупотребительных моделей, используемых разработчиками программного обеспечения для разделения сложных систем на более простые части. В архитектурах компьютерных систем, например, различают слои:

кода на языке программирования;
функций операционной системы;
драйверов устройств;
наборов инструкций центрального процессора и внутренней логики чипов

Layering

Разделение системы на слои предоставляет целый ряд преимуществ:

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

Layering

Схема расслоения обладает и определенными недостатками:

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

Main Layer

Представление (Presentation) - предоставление услуг, отображение данных, обработка событий пользовательского интерфейса (щелчков кнопками мыши и нажатий клавиш), обслуживание запросов HTTP, поддержка функций командной строки и API пакетного выполнения
Домен (Domain) - бизнес-логика приложения
Источник данных (Data Source) - обращение к базе данных, обмен сообщениями, управление транзакциями и т.д.

View

Слой представления охватывает все, что имеет отношение к общению пользователя с системой. Он может быть настолько простым, как командная строка или текстовое меню, но сегодня пользователю, вероятнее всего, придется иметь дело с графическим интерфейсом, оформленным в стиле толстого клиента (Windows, Swing и т.п.) или основанным на HTML. К главным функциям слоя представления относятся отображение информации и интерпретация вводимых пользователем команд с преобразованием их в соответствующие операции в контексте домена (бизнес-логики) и источника данных.

Data source

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

Domain

Логика домена (бизнес-логика или логика предметной области) описывает основные функции приложения, предназначенные для достижения поставленной перед ним цели. К таким функциям относятся вычисления на основе вводимых и хранимых данных, проверка всех элементов данных и обработка команд, поступающих от слоя представления, а также передача информации слою источника данных.

Modularity

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

Modularity

Принципы построения модулей:

логическая завершенность. Функция (модуль) должна реализовывать логически законченный, целостный алгоритм;
ограниченность. Функция (модуль) должна быть ограничена в размерах, в противном случае ее необходимо разбить на логически завершенные части - модули, вызывающие друг друга;
замкнутость. Функция (модуль) не должна использовать глобальные данные, иметь «связь с внешним миром» помимо программного интерфейса;

Modularity

универсальность. Функция (модуль) должна быть универсальна, параметры процесса обработки и сами данные должны передаваться извне, а не должны подразумеваться или устанавливаться постоянными;
принцип «черного ящика». Функция (модуль) должна иметь продуманный «программный интерфейс» - набор фактических параметров и результат функции, через который она «подключается» к другим частям программы (вызывается).

Modularity

Связанность (coupling) — степень взаимозависимости модулей. При создании систем необходимо стремиться к максимальной независимости модулей, т.е. связанность модулей должна быть минимальной.

Principles of development

Разделение ответственности (Separations of concerns) — это упрощение единого процесса решения задачи путём разделения на взаимодействующие процессы по решению подзадач.

KISS (keep it simple, stupid) - принцип, запрещающий использование более сложных средств, чем необходимо, декларирует простоту системы в качестве основной цели и/или ценности.

DRY (Don’t repeat yourself) - принцип разработки, нацеленный на снижение повторения информации различного рода, особенно в системах со множеством слоёв абстрагирования.

MVC

Model–view–controller (MVC) - схема использования нескольких шаблонов проектирования, с помощью которых модель приложения, пользовательский интерфейс и взаимодействие с пользователем разделены на три отдельных компонента таким образом, чтобы модификация одного из компонентов оказывала минимальное воздействие на остальные.

MVC

Основная цель применения этой концепции состоит в отделении бизнес-логики (модели) от её визуализации (представления, вида)

Model

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

const todoModel = new CustomMVC.Model({
  todos: [
    {
      id: _.uniqueId('todo_id'),
      title: 'tttt',
      done: false
    },
    {
      id: _.uniqueId('todo_id'),
      title: 'new',
      done: true
    }
  ]
});

Model

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

View

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

View

const todoView = new CustomMVC.View({
  el: '#todo',
  template: _.template($('.todo-template').html()),

  events: {
    'click .todo__complete': 'toggleComplete',
    'submit #todo__create': 'create',
    'click .todo__btn-edit': 'edit',
    'click .todo__btn-destroy': 'destroy'
  },

  init(model) {
    this.model = model;
    this.render(model.toJSON());

    this.on(`${ this.model.id }update`, this.render.bind(this));
  },

  render() {
  },

  create(e) {
  },

  edit(e) {
  },

  destroy(e) {
  }
});

export default todoView;

Controller

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

Controller

const todoController = new CustomMVC.Controller({
  model: todoModel,

  view: todoView,

  initialize: function () {
    this.view.init(this.model);

    return this;
  }
});

export default todoController;

Motivation

Наличие подобного разделения весьма важно по ряду причин:

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

Motivation

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

Dependencies

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

MVP

Presenter — представитель; реализует взаимодействие между моделью и представлением.

MVP

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

Признаки презентера:

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

MVVM

Данный подход позволяет связывать элементы представления со свойствами и событиями View-модели. Можно утверждать, что каждый слой этого паттерна не знает о существовании другого слоя.

Признаки View-модели:

Двухсторонняя коммуникация с представлением;

View-модель — это абстракция представления. Обычно означает, что свойства представления совпадают со свойствами View-модели / модели

View-модель не имеет ссылки на интерфейс представления (IView).

Изменение состояния View-модели автоматически изменяет представление и наоборот, поскольку используется механизм связывания данных (Bindings)

Один экземпляр View-модели связан с одним отображением.

MV*

MVC & Observer

При использованиитолстого клиента с множеством диалоговых окон на экране могут одновременно находиться несколько представлений одной и той же модели. Если пользователь внесет изменения в модель посредством одного представления, эти изменения должны быть отражены и во всех остальных представлениях. Чтобы это было возможным при отсутствии двунаправленной зависимости, необходимо реализовать типовое решение наблюдатель (Observer).

Observer

Назначение

Определяет зависимость типа «один ко многим» между объектами таким образом, что при изменении состояния одного объекта все зависящие от него оповещаются об этом и автоматически обновляются.

Другие названия

Dependents (подчиненные), Publish-Subscribe (издатель-подписчик)

Observer

Участники Observer

Subject - субъект:
- располагает информацией о своих наблюдателях. За субъектом может «следить» любое число наблюдателей;
- предоставляет интерфейс для присоединения и отделения наблюдателей;
Observer - наблюдатель:
- определяет интерфейс обновления для объектов, которые должны быть уведомлены об изменении субъекта;

Участники Observer

ConcreteSubject - конкретный субъект:
- сохраняет состояние, представляющее интерес для конкретного наблюдателя ConcreteObserver;
- посылает информацию своим наблюдателям, когда происходит изменение
ConcreteObserver - конкретный наблюдатель:
- хранит ссылку на объект класса ConcreteSubject;
- сохраняет данные, которые должны быть согласованы с данными субъекта;
- реализует интерфейс обновления, определенный в классе Observer, чтобы поддерживать согласованность с субъектом.

Dependencies

объект ConcreteSubject уведомляет своих наблюдателей о любом изменении, которое могло бы привести к рассогласованности состояний наблюдателя и субъекта;
после получения от конкретного субъекта уведомления об изменении объект ConcreteObserver может запросить у субъекта дополнительную информацию, которую использует для того, чтобы оказаться в состоянии, согласованном с состоянием субъекта

Observer (JavaScript implementation)

Классический:

https://github.com/aleksuk/GOF-patterns-JavaScript/blob/master/observer/classic-observer.js

Более универсальный и используемый вид:

https://github.com/aleksuk/GOF-patterns-JavaScript/blob/master/observer/observer-example.js

Mediator

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

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

Mediator

Назначение:

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

Другие названия:

Посредник, шина событий

Mediator

Назначение:

Другие названия:

Посредник, шина событий

Mediator

Участники Mediator

Mediator - посредник
- определяет интерфейс для обмена информацией с объектами Colleague
ConcreteMediator - конкретный посредник
- реализует кооперативное поведение, координируя действия объектов Colleague
- владеет информацией о коллегах
Colleague - коллеги
- каждый класс Colleague «знает» о своем объекте Mediator
- все коллеги обмениваются информацией только с посредником, так как при его отсутствии им пришлось бы общаться между собой напрямую

Dependencies

Коллеги посылают запросы посреднику и получают запросы от него. Посредник реализует кооперативное поведение путем переадресации каждого запроса подходящему коллеге (или нескольким коллегам).

Mediator (JavaScript implementation)

Классический:

https://github.com/aleksuk/GOF-patterns-JavaScript/blob/master/mediator/classic-mediator-2.js

Более универсальный и используемый вид:

https://github.com/aleksuk/GOF-patterns-JavaScript/blob/master/mediator/mediator-example.js

SOLID

S - Single responsibility principle

O - Open/closed principle

L - Liskov substitution principle

I - Interface segregation principle

D - Dependency inversion principle

SOLID

Single responsibility principle (Принцип единственной обязанности) - на каждый класс должна быть возложена одна-единственная обязанность
Open/closed principle (Принцип открытости/закрытости) - Программные сущности должны быть открыты для расширения, но закрыты для изменения
Liskov substitution principle (Принцип подстановки Барбары Лисков) - Функции, которые используют базовый тип, должны иметь возможность использовать подтипы базового типа, не зная об этом. Подклассы не могут замещать поведения базовых классов. Подтипы должны дополнять базовые типы.

SOLID

Interface segregation principle (Принцип разделения интерфейса) - много специализированных интерфейсов лучше, чем один универсальный
Dependency inversion principle (Принцип инверсии зависимостей) - зависимости внутри системы строятся на основе абстракций. Модули верхнего уровня не зависят от модулей нижнего уровня. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

Abstraction

Абстрагирование - выделение существенных характеристики некоторого объекта, отличающие его от всех других видов объектов (концентрация внимания на общих свойствах и игнорирование различий).

Scalability

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

Links

JS-MV*

By Oleg Rovenskyi

JS-MV*

MV*

JS

JS-MV*

More from Oleg Rovenskyi