Ооп. 73. Паттерны поведения. Паттерн Visitor (Посетитель)

• Название: 73. Паттерны поведения. Паттерн Visitor (Посетитель)
• Дата: 20.12.2022
• Размер: 132.84 Kb.
• Имя файла: 73-76.docx
• Тип: Документы; #854614

73. Паттерны поведения. Паттерн Visitor (Посетитель)

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

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

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

Всё-таки изменить классы придётся. Но это простое изменение позволит применять к объектам этих классов и другие поведения, ведь классы будут привязаны не к конкретному классу посетителей, а к их общему интерфейсу. Поэтому если придётся добавить в программу новое поведение, вы создадите новый класс посетителей и будете передавать его в методы узлов.

74. Архитектурные паттерны: MVC

Модель

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

Модель обладает следующими признаками:

• 
  Модель — это бизнес-логика приложения;
  
• 
  Модель обладает знаниями о себе самой и не знает о контроллерах и представлениях;
  
• 
  Для некоторых проектов модель — это просто слой данных (DAO, база данных, XML-файл);
  
• 
  Для других проектов модель — это менеджер базы данных, набор объектов или просто логика приложения;
  

Представление (View)

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

Представление обладает следующими признаками:

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

Примеры представления: HTML-страница, WPF форма, Windows Form.

Model-View-Controller



Основная идея этого паттерна в том, что и контроллер и представление зависят от модели, но модель никак не зависит от этих двух компонент.

Признаки контроллера

• 
  Контроллер определяет, какие представление должно быть отображено в данный момент;
  
• 
  События представления могут повлиять только на контроллер.контроллер может повлиять на модель и определить другое представление.
  
• 
  Возможно несколько представлений только для одного контроллера;
  

Реализация:

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

Пример использования: MVC ASP.NET

75. Архитектурные паттерны: MVP

Модель

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

Модель обладает следующими признаками:

• 
  Модель — это бизнес-логика приложения;
  
• 
  Модель обладает знаниями о себе самой и не знает о контроллерах и представлениях;
  
• 
  Для некоторых проектов модель — это просто слой данных (DAO, база данных, XML-файл);
  
• 
  Для других проектов модель — это менеджер базы данных, набор объектов или просто логика приложения;
  

Представление (View)

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

Представление обладает следующими признаками:

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

Примеры представления: HTML-страница, WPF форма, Windows Form.

Model-View-Presenter



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

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

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

Реализация:

Каждое представление должно реализовывать соответствующий интерфейс. Интерфейс представления определяет набор функций и событий, необходимых для взаимодействия с пользователем (например, IView.ShowErrorMessage(string msg)). Презентер должен иметь ссылку на реализацию соответствующего интерфейса, которую обычно передают в конструкторе.

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

Пример использования: Windows Forms.

76. Архитектурные паттерны: MVVM

Модель

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

Модель обладает следующими признаками:

• 
  Модель — это бизнес-логика приложения;
  
• 
  Модель обладает знаниями о себе самой и не знает о контроллерах и представлениях;
  
• 
  Для некоторых проектов модель — это просто слой данных (DAO, база данных, XML-файл);
  
• 
  Для других проектов модель — это менеджер базы данных, набор объектов или просто логика приложения;
  

Представление (View)

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

Представление обладает следующими признаками:

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

Примеры представления: HTML-страница, WPF форма, Windows Form.

Model-View-View Model



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

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

• 
  Двухсторонняя коммуникация с представлением;
  
• 
  View-модель — это абстракция представления. Обычно означает, что свойства представления совпадают со свойствами View-модели / модели
  
• 
  View-модель не имеет ссылки на интерфейс представления (IView). Изменение состояния View-модели автоматически изменяет представление и наоборот, поскольку используется механизм связывания данных (Bindings)
  
• 
  Один экземпляр View-модели связан с одним отображением.
  

Реализация:

При использовании этого паттерна, представление не реализует соответствующий интерфейс (IView).

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

В свою очередь, View-модель реализует специальный интерфейс, который используется для автоматического обновления элементов представления. Примером такого интерфейса в WPF может быть INotifyPropertyChanged.

Пример использования: WPF