我“得到”了吗？

对不起，还不完全是。

Context Object的目标不是将大量参数隐式传递给方法，这是绕过强类型和封装的一种方法。目标是以通用但受管理的方式存储范围内的数据，而与协议和表示技术无关。本质上，存储在范围内的数据是共享的，仍然可以进行结构化，并且与传递给方法的一次性参数本质上不同。

上下文对象模式最初是在Core J2EE Patterns 2nd Ed中引入的。“上下文”部分是指对象在范围 的上下文
（例如application/session/request/conversation/flash）的上下文中保存数据的事实。

其目的是尽可能将应用程序数据和逻辑与特定于协议/表示技术的类（例如HttpSession和）分离HttpRequest。

模式实施

下上下文对象，用于应用/会话/请求数据/其他范围并不直接放入ServletContext/ HttpSession/ HttpRequest/其它特定于协议的类。取而代之的是，数据存储在一个POJO包装类，即随后在坐在ServletRequest/ HttpSession/ HttpRequest/其它。

上下文对象可以将数据存储在映射中，但是不需要-它可以以与程序相关的任何结构/格式存储数据。

应用程序可以在每个作用域中使用一个上下文对象类，也可以使用多个类以有序的方式拆分数据，从而避免过多的类膨胀并促进关注点分离。

上下文对象由最前面的表示形式类（视图，前端控制器，调度程序）使用。这些演示客户端对象调用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：我想你明白了。但是，我也认为这更多是要避免的反模式。在这里看看为什么。