Presentation Context

1. 目的

使界面代码承担的职责更少，便于代码的维护，提高代码可读性。

2. 动机

我们在编写客户端代码的时候，经常会用到字符资源、图片资源以及多个View 间共享实例，这些职责如果由View 自己负责，一方面，降低了代码的重用性(资源加载的代码)，另一方面，也使View 承担了更多的职责，不利用View 的维护。如果这部分职责由外部实现，View 又如何访问这些资源。这就是Presentation Context 的模式所要解决的问题。

3.参与者

1. Presentation Context：它封装了View 在创建时所需要的上下文信息，并且可以作为多个View 之间共享对象的容器。

2. Component Factory：它负责创建Swing 控制和平台自定义的控制。使用Componet Factory 的好处是可以统一的控制系统内部的控件，例如：通过Component Factory 创建的对话框都可以点击Esc 键关闭，点击F1 出现Help 对话模式。

4. 特点

1. 优点：（1）使用Presentation Context 可是分解View 的职责，使View 的代码更容易维护。 （2） 使加载资源的代码可以被重用。（3）使多个View 间可以方便的共享对象。（4）使View 更容易访问客户端平台开放的接口。

5. 实现

1) ComponentFactory 接口代码

2) ImageResourceFactory 接口代码

3) PresentationContext 接口代码

4) SampleView 代码

说明：

1) SampleView 中的文本资源和图片资源都是外部进行加载的，一般应用时可以由平台提供代码实现，然后各模块自己注入相应的路径。

2) SampleView 中的dialog 都是由平台提供的ComponentFactory 进行创建的，实现时平台可以在创建时，默认注册Esc 键的Listener。

6. 注意事项

1.Presentation Context 可以包含更多与特定客户端平台相关的内容，在应用时可以根据具体情况使用，但是要注意它里面不应该包含和领域逻辑相关的任何内容。

2.一个模块应该只有一个Presentation Context 实例，最好由平台创建或者有模块的Facade 负责创建。

没有人参与讨论吗？

怎么没人回应呀？这种模式是好还是坏，还是根本就不值得一提呀？

给个具体的例子吧...

我会尽快补充一个代码示例。

代码示例补充完毕。

有人关心吗？这个模式我已经在我的项目中应该了多次，
如果大家不能够看懂模式，可以告诉我，我再修改一下。

很不错的架构.

Context就像是在Model和View之间再加了一层.
只是像ComponentFactory这种会不会显得很庸肿?

ComponentFactory 是一个抽象工厂，用于创建平台系列的组件，当我们的模块被加入到不同的平台时组件可以有不同的实现，这样的好处有是：平台的一些特性可以统一被处理，不需要在模块代码中零碎增加处理平台特性的代码。