Шаблоны проектирования GRASP

GRASP (англ. General Responsibility Assignment Software Patterns (общие образцы распределения обязанностей)) - паттерны, используемые в объектно-ориентированном проектировании для решения общих задач по назначению обязанностей классам и объектам .

В книге Крейга Лармана «Применение UML и шаблонов проектирования» описано 9 таких образцов. Каждый из них помогает решить некоторую проблему, возникающую при объектно-ориентированном анализе, и которая возникает практически в любом проекте по разработке программного обеспечения. Таким образом, GRASP-паттерны - это хорошо документированные, стандартизированные и проверенные временем принципы объектно-ориентированного анализа, а не попытка привнести что-то принципиально новое.

Каталог паттернов

Ниже следует краткая характеристика девяти известных паттернов.

Information Expert (Информационный эксперт)

Шаблон Information Expert определяет базовый принцип назначения обязанностей. Он утверждает, что обязанности должны быть назначены объекту, который владеет максимумом необходимой информации для выполнения обязанности. Такой объект называется информационным экспертом . Возможно, этот шаблон является самым очевидным из девяти, но вместе с тем и самым важным.

Если дизайн не удовлетворяет этому принципу, то при программировании получается спагетти-код , в котором очень трудно разбираться. Локализация обязанностей позволяет повысить уровень инкапсуляции и уменьшить уровень связанности . Кроме читабельности кода повышается уровень готовности компонент к повторному использованию.

Creator (Производитель)

Паттерн Creator решает, кто должен создавать объект. Фактически, это применение шаблона Information Expert к проблеме создания объектов. Более конкретно, нужно назначить классу B обязанность создавать экземпляры класса A, если выполняется как можно больше из следующих условий:

• Класс B содержит (contains) или агрегирует (aggregate) объекты A.
• Класс B записывает (records) экземпляры объектов A.
• Класс B активно использует (closely uses) объекты A
• Класс B обладает данными инициализации (has the initializing data) для объектов A.

Альтернативой производителю является образец Фабрика . В этом случае создание объектов концентрируется в отдельном классе.

Controller (Контроллер)

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

Иногда класс-контроллер представляет всю систему в целом, корневой объект, устройство или важную подсистему (внешний контроллер ).

Low Coupling (Слабая связанность)

Low Coupling - это оценочный образец (или принцип), который устанавливает следующие свойства:

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

High Cohesion (Сильное сцепление)

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

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

Polymorphism (Полиморфизм)

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

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

Pure Fabrication (Чистая выдумка)

Чистая выдумка - это класс, не отражающий никакого реального объекта предметной области, но специально придуманный для усиления связности, ослабления связанности или увеличения степени повторного использования. Pure Fabrication отражает концепцию сервисов в модели Программирование от предметной области.

Indirection (Посредник)

Образец Indirection поддерживает слабую связанность (и возможность повторного использования) путём назначения обязанностей посредника между ними промежуточному объекту. Пример: образец

Protected Variations (Сокрытие реализации)

Образец Protected Variations защищает элементы от изменения других элементов (объектов или подсистем) с помощью вынесения взаимодействия в фиксированный

GRASP (General Responsibility Assignment Software Patterns - общие образцы распределения обязанностей) - паттерны, используемые в объектно-ориентированном проектировании для решения общих задач по назначению обязанностей классам и объектам.

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

Information Expert (Информационный эксперт)

Шаблон Information Expert определяет базовый принцип назначения обязанностей. Он утверждает, что обязанности должны быть назначены объекту, который владеет максимумом необходимой информации для выполнения обязанности. Такой объект называется информационным экспертом . Возможно, этот шаблон является самым очевидным из девяти, но вместе с тем и самым важным.

Если дизайн не удовлетворяет этому принципу, то при программировании получается спагетти-код , в котором очень трудно разбираться. Локализация обязанностей позволяет повысить уровень инкапсуляции и уменьшить уровень связанности . Кроме читабельности кода повышается уровень готовности компонент к повторному использованию.

Creator (Создатель)

Шаблон Creator решает, кто должен создавать объект. Фактически, это применение шаблона Information Expert к проблеме создания объектов. Более конкретно, нужно назначить классу B обязанность создавать экземпляры класса A, если выполняется как можно больше из следующих условий:

• Класс B содержит или агрегирует объекты A.
• Класс B записывает экземпляры объектов A.
• Класс B активно использует объекты A
• Класс B обладает данными инициализации для объектов A.

Альтернативой создателю является шаблон проектирования Фабрика . В этом случае создание объектов концентрируется в отдельном классе.

Controller (Контроллер)

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

Иногда класс-контроллер представляет всю систему в целом, корневой объект, устройство или важную подсистему (внешний контроллер ).

Использование контроллеров позволяет отделить логику от представления, тем самым повышая возможность повторного использования кода.

Low Coupling (Слабая связанность)

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

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

Low Coupling позволяет избежать следующих проблем:

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

High Cohesion (Сильное зацепление)

High Cohesion - это принцип, который задаёт свойство сильного зацепления внутри подсистемы. Классы (подсистемы) таким образом получаются сфокусированными, управляемыми и понятными. Зацепление (cohesion) (или более точно, функциональное зацепление) - это мера связанности и сфокусированности обязанностей класса. Считается что объект (подсистема) обладает высокой степенью зацепления, если его обязанности тесно связаны между собой и он не выполняет огромных объемов работы.

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

• Трудность понимания.
• Сложность при повторном использовании.
• Сложность поддержки.
• Ненадежность, постоянная подверженность изменениям.

Классы с низкой степенью зацепления, как правило, являются слишком «абстрактными» или выполняют обязанности, которые можно легко распределить между другими объектами.

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

Polymorphism (Полиморфизм)

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

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

Pure Fabrication (Чистая выдумка)

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

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

Indirection (Посредник)

Indirection поддерживает слабую связанность (и возможность повторного использования) путём назначения обязанностей посредника между ними промежуточному объекту. Пример: Model-View-Controller , который позволяет ослабить связь между данными и их представлением с помощью введения класса-посредника (контроллер), отвечающего за поведение.

Protected Variations (Сокрытие реализации)

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

Advertisements

GRASP (General Responsibility Assignment Software Patterns) - паттерны проектирования, используемые для решения общих задач по назначению обязанностей классам и объектам .

Известно девять GRAPS паттернов, изначально описанных в книге Крейга Лармана «Применение UML и шаблонов проектирования». В отличие от рассмотренных ранее паттернов GoF, GRAPS паттерны не имеют выраженной структуры, четкой области применения и конкретной решаемой проблемы, а представляют собой обобщенные подходы, используемые при проектировании дизайна системы. Формально их можно отнести к принятой в GoF классификации на порождающие, структурные и паттерны поведения.

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

Головной офис компании состоит из трех отделов: отдел по работе с клиентами, отдел диспетчеризации рейсов, отдел комплектации рейсов. Менеджеры из отдела по работе с клиентами оформляют договоры на доставку груза из пункта А в пункт В. Диспетчеры из отдела диспетчеризации рейсов отслеживают положение судов. Администраторы из отдела комплектации рейсов формируют грузовые рейсы на основании договоров с клиентами.

Информационный эксперт (Information Expert) -

структурный паттерн

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

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

Низкая связанность (Low Coupling) - структурный -

и Высокое зацепление (High Cohesion) - паттерн поведения

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

Примером хорошего дизайна системы может служить набор утилит GNU Binutils для Linux, где каждая утилита (если ее рассматривать как модуль) выполняет лишь минимальные обязанности (высокое зацепление) и почти ничего не знает о природе других утилит (низкая связность), в связи с чем может быть легко заменена на аналог в некотором варианте использования.

Устойчивый к изменениям (Protected Variantions) - структурный

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

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

Контроллер (Controller) - паттерн поведения

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

Известно понятие внешнего Контроллера (Front Controller), который представляет всю систему в целом (агрегирует весь функционал системы в одном классе).

Примером Контроллера является класс Administrator, реализующий вариант использования системы администраторов из отдела комплектации рейсов. Использование Контроллеров позволяет отделить логику от представления, тем самым повышая возможность повторного использования кода.

Полиморфизм (Polymorphism) - паттерн поведения

Паттерн Полиморфизм позволяет обрабатывать альтернативные варианты поведения на основе типа. При этом альтернативные реализации приводятся к обобщенному интерфейсу. Рассмотрим интеграцию системы с внешними компонентами расчета тарифов на перевозку груза. Классы Loca/Tarificator и WorldWideTarificator являются Адаптерами к соответствующим внешним компонентам. Применение паттерна Полиморфизм позволяет в будущем легко модифицировать систему.

Чистая выдумка (Pure Fabrication) - паттерн поведения

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

Перенаправление (Indirection) - паттерн поведения

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

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

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

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

Разные принципы для одинаковых моделей

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

Да, моделировать — не сложно. Только проблема в том, что мы все-таки имеем дело всего лишь с моделью. А когда объекты (сущности) уже созданы, тогда вступает в игру именно их программирование и проектирование. Объекты должны взаимодействовать, и при этом модель должна быть гибкой, однородной и простой. Вот тут нам и помогают универсальные принципы, которые, повторюсь, во многом близки по смыслу шаблонам.

Основной вопрос на который дает ответ высокая сцепленность — «Как поддерживать объекты сфокусированными на одной ответственности, понятными, управляемыми и как побочный эффект иметь слабо связанный код?»

Их нужно разделять. Подробнее это описано в 17 главе вышеупомянутой книги Лармана .

Pure Fabrication

Pure Fabrication или чистая выдумка , или чистое синтезирование. Здесь суть в выдуманном объекте. Вот такой себе принцип-хак! Но без него никак. Аналогом может быть шаблон Service (сервис) в .

Иногда, сталкиваемся с таким вопросом: «Какой объект наделить ответственностью, но принципы информационный эксперт , высокая сцепленность не выполняются или не подходят?». Тогда нужно использовать синтетический класс который обеспечивает высокую сцепленность. Тут без примера точно не разобраться.

Итак — ситуация. Какой класс должен сохранять наш объект Sale в базу данных? Если подчиняется принципу «информационный эксперт », то Sale , но наделив его такой ответственностью мы получаем слабую сцепленность внутри него. Тогда можно найти выход, создав синтетическую сущность — SaleDao или SaleRepository , которая будет сильно сцеплена внутри и будет иметь единую ответственность — и правильно сохранять Sale в базу.

Так как мы выдумали этот объект, а не спроектировали с предметной области, то и он подчиняется принципу «чистая выдумка ».

Indirection

Indirection или посредник . Можно столкнуться с таким вопросом: «Как определить ответственность объекта и избежать сильной связанности между объектами, даже если один класс нуждается в функционале (сервисах), который предоставляет другой класс?» Необходимо наделить ответственностью объект посредник.

Например, возвратимся опять же MVC. UI-логике на самом деле нужен не контроллер, а модель, доменная логика. Но мы не хотим? чтобы UI-логика была сильно связанна с моделью, и возможно в UI мы хотим получать данные и работать с разной предметной логикой. А связывать UI-слой с бизнес логикой было бы глупо, потому что получим код который будет сложный для изменений и поддержки. Выход — вводим контроллер как посредник между View и Model.

Так что распределяйте ответственности всем своим объектам ответственно (с умом).

Protected Variations

Protected Variations или сокрытие реализации , или иначе защищенные изменения . Как спроектировать объекты, чтобы изменения в объекте или объекта не затрагивали других? Как избежать ситуации, когда меняя код одного объекта придется вносить изменения в множество других объектов системы?

Кажется мы такое обсуждали уже. И пришли к выводу, что нужно использовать low coupling или dependency injection . Именно! Но суть текущего принципа немного в другом. Суть в том, чтобы определить «точки изменений» и зафиксировать их в абстракции (интерфейсе). «Точки изменений» — не что иное, как наши объекты, которые могут меняться.

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

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

Polymorphism

Polymorphism или полиморфизм . Тоже знакомо, не так ли? Так вот это об том же полиморфизме, который мы знаем из ООП. Если заметить, то достаточно много , да и вообще паттернов, построено на полиморфизме. Что он дает? Он дает возможность трактовать однообразно разные объекты с одинаковым интерфейсом (спецификацией). Давайте вспомним такие паттерны как Strategy , Chain of Resposibility , Command ... — их много ещё всяких. И все по своей сути основываются на полиморфизме.

Полиморфизм решает проблему обработки альтернативных вариантов поведения на основе типа. Яркий пример этого — шаблон из GoF, — Strategy (Стратегия).

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

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

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

В заключение — принципы GRASP не создают четкую структуру, которой мы должны следовать в коде. Это больше глубоко продуманное распределение ролей и ответственностей между всеми объектами, а также свойства, которыми эти объекты должны обладать для того, чтобы гармонично исполнять свои роли

И как всегда в заключение, даю наводки на дополнительные материалы по рассмотренной сегодня теме:

Также для закрепления темы хорошая презентация на русском.

2 мая 2010 в 16:34

GRASP паттерны проектирования

• Совершенный код

Известно понятие внешнего контроллера (Front Controller), который представляет всю систему в целом (агрегирует весь функционал системы в одном классе).

Примером контроллера является класс Administrator, реализующий вариант использования системы администратором из отдела комплектации рейсов.

Использование контроллеров позволяет отделить логику от представления, тем самым повышая возможность повторного использования кода.

Полиморфизм (Polymorphism)

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

Рассмотрим интеграцию системы с внешними компонентами расчета тарифов на перевозку груза. Классы LocalTarificator и WorldWideTarificator являются адаптерами к соответствующим внешним компонентам.

Применение шаблона полиморфизм позволяет в будущем легко модифицировать систему.

Чистая выдумка (Pure Fabrication)

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

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

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

Перенаправление (Indirection)

Шаблон перенаправление реализует низкую связность между классами, путем назначения обязанностей по их взаимодействию дополнительному объекту - посреднику.

Примером данного шаблона может служить класс ClientsSaver (см. Чистая выдумка), который является промежуточным слоем между сущностями клиентов и хранилищем, в котором они будут сохранены. Кроме того, контроллер из триады MVC является посредником между данными их их представлением.