Swing 模型过滤

         简介

　　模型过滤是这样一种技术，它在 Swing 组件体系结构中提供附加的功能与灵活性。

　　Swing 体系结构的重要创新之一在于采用了模型/视图/控制器 (MVC) 原理，这样就可将组件的不同角色分离开。当一种体系结构具备 MVC 分离特性时，即可对组件的数据与状态作不同的解释。这允许程序员在组件及其模型之间插入过滤器对象。模型过滤可以在模型内修改数据的表示，还也可以改变模型所封装数据的外在数目和顺序。

　　模型过滤器的另外两种重要特性是：

　　模型过滤操作不会改变底层的模型数据。这使得多个组件可以共享一组数据，而且每个组件都可能以不同的方式解释这组数据。

　　过滤器可以叠用，这样就可以依次用几个不同的过滤器对象来解释模型数据。

　　已定义的代理

　　为了最大限度地利用 Java 平台对面向对象的支持，可以简单地认为组件由若干对象构成。这些对象可以由一个通用术语 ― 代理 ― 来描述。代理是实现一个公共 Java 接口并与某个特定组件相关联的对象。代理实现的接口定义代理在 MVC 体系结构中充当的角色。

　　对于刚刚接触 Swing 的程序员而言，代理的概念似乎有些难以理解，但是，它们也是 AWT 组件的一种共同特征。例如，如果想更改 java.awt.Label 组件上的字体，只需创建或获取 java.awt.Font 类的一个实例，并且调用 getFont() 使该实例与组件相关联。Font 对象的内部运作细节可能很有趣，但是组件只要有 Font 类型对象的一个引用即可适当地显示自己。甚至像标签前景颜色这种简单概念也是通过代理实现的;java.awt.Color 类提供一种适合作组件前景颜色的对象。作为一般规则，值为非基本数据类型的各种组件属性都可看作是代理。

　　Swing 中的 MVC 实现就是这些概念的体现。对象不仅用于表示组件的属性值，也用于表示组件行为的诸多方面。这种方案相当灵活，足以支持 Swing 的可插接外观 (PLAF) 功能的实现，该功能使应用程序既可模拟本地平台的外观，也可用一种与平台无关的方案显示组件。PLAF 既可使应用程序看起来就像 Microsoft Windows、 Mac OS 和 X/Motif 等平台的本地应用程序一样，也可使应用程序具有一种中立的外观，称为 "Java" LAF 或 "Metal" LAF。

　　PLAF 功能与组件的外观密切相关。本文主要讨论这一体系结构的模型部分，它与组件的外观的无关。

　　作为一种模型(或类似一种模型)

　　每种支持数据与状态的 Swing 组件都有一种与之相关的模型接口。无论接口感兴趣的是封装于该模型的数据还是状态，它都会包含允许组件以编程方式查询模型内容的若干方法。

　　每个模型接口都提供两类方法：一类方法提供对数据与状态的访问，而另一类方法允许组件或者其他对象注册或取消注册事件监听程序。监听程序的类型及其提供的事件对象都由这些方法定义。

　　Swing 模型接口可以有不同类型的类实现。在许多情况下，为模型提供的是一种抽象实现;除了为了触发模型所表示的各种事件方法而提供的 protected 方法之外，这通常是一种不完全的正则实现。所有模型都有一个缺省实现，并且是一个具体类。

　　既好又简单 ― ListModel 接口

　　在开始讨论过滤之前，对典型的模型接口作一回顾不失为明智之举。

　　ListModel 接口代表 JList 组件中的数据。这是三种集合模型中最简单的一种。(另外两种分别是 JTree 和 JTable。) ListModel 有两个方法用于检索列表中的元素个数以及各个元素，另外还有两个方法用于维护感兴趣的监听程序列表，以便监听列表模型的变化。

　　ListModel 的简化源代码

　　在 ListModel 接口中， getSize() 与 getElementAt() 方法用于遍历模型中的元素，而其他两个方法用于建立与感兴趣的监听程序之间的关联，以便监听模型的变化。

　　ListDataListener 接口支持三个方法，当模型监听到其底层数据发生变化时就会调用这三个方法。这三个方法是 intervalAdded() 、 intervalRemoved() 和 contentsChanged() ，每个方法都接受单个 ListDataEvent 作为参数。根据模型所发生变化的复杂程度之不同，模型实现可以使用其中的任一个方法来描述这些变化。通常， intervalAdded() 和 intervalRemoved() 用于描述变化的时间间隔;当变化过于复杂，无法作为一个闭合间隔进行描述时，就会用到 contentsChanged() 。

　　为了理解模型过滤如何运作，请记住这一点：JList 组件只对 ListModel API 的实现感兴趣。该组件并不关心数据驻留何处以及数据是如何组织的。无论该模型是一个缺省类、抽象类的扩展，还是 ListModel 接口的一种直接实现，都不影响 JList 组件的行为