Можете ли вы объяснить шаблон дизайна контекста?

Ответ 1

Я думаю, вы поняли.

Однако я также считаю, что это скорее анти-шаблон, которого следует избегать. Смотрите, почему здесь.

См. также Закон Деметры

Ответ 2

Я получил его?

Простите, не совсем.

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

Шаблон контекстного объекта был впервые представлен в Core J2EE Patterns 2nd Ed. Часть "Контекст" ссылается на то, что объект хранит данные в контексте области действия (например, application/session/request/conversation/flash).

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

Реализация шаблонов

В разделе "Контекстный объект" данные, предназначенные для области приложения/сеанса/запроса/другой, не помещаются непосредственно в класс ServletContext/HttpSession/HttpRequest/другого класса, специфичного для протокола. Вместо этого данные сохраняются в классе оболочки POJO, который затем находится в ServletRequest/HttpSession/HttpRequest/other.

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

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

Объект контекста используется передними классами презентаций (Views, Front Controllers, Dispatchers). Эти объекты-клиенты представления вызывают contextObject.get для извлечения данных с сохраненными областями и contextObject.put для хранения скоординированных данных контекста.

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

Преимущества шаблонов

• Тестируемость: модульные тесты должны только высмеивать простой POJO, а не сложный серверный класс, специфичный для протокола, например ServletContext или HttpRequest
• Гибкость и повторное использование: ядро ​​приложения работает независимо от тонкого класса классов "презентация". Это означает, что приложение может более легко изменять или добавлять протоколы или технологию представления (например, HTML/HTTP/Servlet и WAP/Servlet и XML/SOAP/HTTP/EJB и HTML/HTTP/JSF).

Комментарии

• Является историческим шаблоном
• Можно утверждать, что инфраструктура инъекций зависимостей, такая как CDI, Guice, Spring, Seam и другие, предоставляет хранилище областей, уже реализованное независимым от протокола образом. то есть все облачные объекты реализованы как объекты контекста уже, что означает, что разработчик менее вынужден создавать дополнительные объекты контекста. Это не отрицает шаблон - это означает, что среда CDI уже поддерживает шаблон.
• Если это неверно реализовано, вы можете получить "Пропустить круглые объекты контекста в приложении" antipattern

Цитата KaptajnKold: Думаю, ты понял. Тем не менее, я также думаю, что это скорее анти-шаблон, которого следует избегать. Посмотрите, почему здесь.

Ваши комментарии относятся к недооцененной версии Контекстного объекта. Сам контекстный объект не является анти-шаблоном.

Ответ 3

Объект контекста обеспечивает доступ к общим данным и функциям.

Это может быть элегантная и гибкая замена:

• globals
• singletons
• списки длинных параметров

ACCU предоставляет более подробное описание.

Если вам нужен реальный пример шаблона контекста в Java, проверьте Google Android API.

При использовании шаблона контекста вы должны помнить свой график зависимостей. (Вот почему KaptajnKold называет это анти-шаблоном.)

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

Ответ 4

Класс, использующий контекст для инициализации. Рассмотрим этот код

public class BuildTagHandler extends TagHandler {

      public BuildTagHandler(ServiceContext context) {  // constructor
            this.tagDAO = context.getTagDAO();
            this.buildDAO = context.getBuildDAO();
      }

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

Вы можете интерпретировать его как шаблон фасада, или огромный интерфейс охватывает все записи.