Я "понял" это?
Извините, не совсем.
Цель Context Object - , а не , чтобы неявно передавать множество параметров в методы, чтобы обойти строгую типизацию и инкапсуляцию. Цель состоит в том, чтобы хранить объемные данные в общем, но управляемом виде, независимо от протоколов и технологии представления. Данные, хранящиеся в области видимости, по своей природе являются общими, все еще могут быть структурированными и по своей природе отличаются от одноразовых параметров, передаваемых методу.
Шаблон объекта контекста был впервые представлен в шаблонах Core J2EE 2nd Ed . Часть «Контекст» относится к тому факту, что Объект содержит данные в контексте scope
(например, application/session/request/conversation/flash
).
Его цель - максимально отделить данные и логику приложения от классов, специфичных для протокола / технологии представления, таких как HttpSession
и HttpRequest
.
Реализация шаблона
В объекте контекста данные, предназначенные для области приложения / сеанса / запроса / другой области, не помещаются непосредственно в ServletContext
/ HttpSession
/ HttpRequest
/ другой специфичный для протокола класс. Вместо этого данные хранятся в классе-оболочке POJO, который затем помещается в ServletRequest
/ HttpSession
/ HttpRequest
/ other.
Объект контекста может хранить данные на карте, но в этом нет необходимости - он может хранить данные в любой структуре / формате, относящихся к программе.
Приложение может использовать один класс объектов контекста для каждой области или несколько классов, которые упорядоченно разделяют данные, избегая чрезмерного раздувания классов и способствуя разделению интересов.
Объект Context используется передними классами представления (Представления, 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 уже поддерживает шаблон.
- При неправильной реализации можно получить анти-паттерн «Обойти гинормальные объекты контекста через приложение»
Цитирование KaptajnKold:
Я думаю, ты понял.
Тем не менее, я также считаю, что этого следует избегать. Узнайте, почему здесь .
Ваши комментарии относятся к неверно реализованной версии Context Object. Сам по себе объект контекста не является анти-паттерном.