开源项目中常有以 Context 命名的类，如 Spring 的 ApplicationContext、Dubbo 的 RpcContext、Netty 的 ChannelHandlerContext 等等。这些类的作用在于传递流程中所用到的各种数据，故称上下文。除了用来满足功能外，上下文类其实背后还体现了一种设计模式，这种设计模式可以帮助我们提升系统的可扩展性。

笔者曾遇到很多系统，业务流程中的某一步因业务原因需要增加功能，而这个功能所需的参数是原来所没有的。因此，实现这个功能的方法首先要增加新参数，而这个参数的生成可能是在很多步之前的一个地方。因此，这个新加了参数的方法调用链上直到参数提供者的每一个环节也都需要增加新参数。如此，一个需求很多地方都需要改动，扩展性可想而知。

Context 模式可以很好地解决这个问题。对于业务核心流程中所用到的主要和次要数据，我们都可以放在 Context 中。当再遇到上述需求时，通常只需直接使用 Context 中的数据即可。即便需要新增加数据，改动点会比不使用 Context 要少很多。

应用范围

Context 可用在系统内部数据传递，或者外部系统向系统内部传递数据。Context 适用于主流程和大部分扩展点的参数传递中。其它地方参数传递需仔细考虑，不易到处使用 Context。随意使用 Context 会导致业务含义不清。

设计实现

Context 不宜直接采用 Map 的形式，而是对其中的主要业务数据有清晰定义。 如 Spring 的 ApplicationContext 的主要业务数据是 Bean，故有 getBean 方法。Netty 的 ChannelHandlerContext 中包含的主要数据有 Channel、ChannelHander、Executor 等，因此也各有相应的方法。通常来说，这些有名有姓的数据是必须的，至少是有默认值的。

Context 在形式上通常是一个接口，其中的主要数据只会有只读方法暴露，避免其它代码任意修改其内容，从而影响功能正常。而对于次要数据，通常会提供一个 Map 形式的存储字段，可读可写。

Context 的具体实现是有系统内部提供。主要数据写入也是有系统内部实现，对于外部系统来说这是一个黑盒过程。

最后

关于 Context 模式就先聊到这里，有任何想法欢迎交流。