视图处理程序
从用户角度，管理多视图应该简单方便，而对系统内客户机组件而言，也应如此。单个视图的实现不应该互相依赖，同时不与用来管理视图的代码相混合。视图的实现可以变化，并且可以在系统生存期中可以加入视图的附加类型。
结构
视图处理程序是这个模式的中心组件。它负责打开新的视图，并且客户机可以说明他们想要的视图。视图处理程序实例化相应的视图组件，维护它正确的初始化，并要求显示自身的新视图。视图处理程序负责处理视图一般操作（最小化、关闭等）。
然而，视图处理程序的主要责任是提供视图管理服务。包括将特定视图放在前景窗口，平铺所有视图，将单个视图分成几个部分，刷新所有视图，复制视图以获得同一文档的多个视图。
视图处理程序的一个附加职责是协调视图之间可能存在依赖性，例如几个视图显示一个复合文档的不同部分。
抽象视图组件定义了所有视图的公共接口。视图处理程序用这个接口来创建、协调以及关闭视图。系统底层平台用该接口来执行用户事件，如重新设定窗口大小。抽象视图的这个接口必须为视图可以实现所有可能的操作提供相应的功能。
特定视图组件是从抽象视图派生而来，并实现抽象视图的接口。此外，每个视图都实现其自身的显示功能。视图从视图供应者处检索数据，准备显示这个数据并将数据呈现给客户。
供应者组件提供了由视图组件显示的数据，供应者提供了允许客户机（比如视图）获得和更改数据的一个接口。供应者通知相关组件有关其内部状态的变化，这些相关组件或是单个的视图，或是在视图处理程序组织更新时视图处理程序自身。
优点
1）视图的统一处理。所有的视图共享公共接口，因此，视图处理程序及系统所有其他的组件都能够一致地处理和操作所有的视图，与它们显示的内容以及实现方法无关。
2）视图的可扩充性及可变更性。在带有抽象库的继承层次中的视图组件组织支持新视图的集成而不改变现有的视图和视图处理程序。由于单个的视图被封装在分离的组件中，因此变更它们的实现不会影响系统的其他组件。
3）特殊应用的视图协调。由于视图被中心程序管理，因此有可能实现特殊的视图协调策略。
不足
1）有限的适用性。只有当系统必须支持许多不同的视图，而视图彼此具有逻辑上的相关性，或者视图可能由不同的供应者或输出设备配置时，使用视图处理程序模式才是值得的。如果系统必须实现特定的视图协调策略，视图处理程序模式也具有使用价值。除了这些应用外，视图处理程序模式只会带来额外的实现工作并且会增加系统内部的复杂性。
2）效率。如果视图处理程序负责组织视图更新，则视图处理程序组件会在需要创建视图的客户机之间以及变更通知的传播链内引入间接方法层，这将导致性能的损失，然而，大部分情况下这些损失是可以忽略的。