第3章Swing组件的体系结构.docVIP

第3章 Swing组件的体系结构 　　轻量Swing组件把它们的界面样式(look and feel)交给一个UI代表来处理，这个UI代表负责绘制组件（即look）并处理组件的事件（即feel)。可在构造组件之时或之后，把UI代表插入这个组件中。“插入式界面样式”这个术语在1.4节中介绍过。　　Swing的插入式界面样式由一个基于Smalltalk的“模型-视图-控制器（Model-View-Controller，MVC）”设计的组件体系结构和用于管理界面样式的下层构件组成。前者是本章重点，首先我们给出典型的MVC的概览，然后再介绍Swing MVC的实现。后者稍后将在第7章中介绍。 3.1 典型的“模型-视图-控制器”体系结构 　　MVC体系结构是为那些需要为同样的数据提供多个视图的应用程序而设计的。MVC把应用程序分为三种对象类型：　　·模型：维护数据并提供数据访问方法。　　·视图：绘制模型的部分数据或所有数据的可视图。　　·控制器：处理事件。　　模型负责维护数据，例如，一个笔记本应用程序将把文档文本存储在模型中。模型通常提供访问和修改数据的方法。当模型变化时，这个模型还把事件发送给已登记的视图，对此，视图根据模型的变化来更新自己。　　视图负责提供模型的部分数据的可视图。例如，一个笔记本应用程序通过显示存储在模型中的部分文本或所有文本来提供当前文档的一个视图。　　控制器为视图处理事件。鼠标和动作监听器等AWT和Swing监听器都是MVC控制器。前面提到的笔记本应用程序应该有鼠标和键盘监听器，以便适时地改变模型或视图。　　MVC需要很强的设计功能。首先，应当可以把多个视图和控制器插入到单个模型中，这是Swing插入式界面样式的基础。　　其次，当模型改变时，模型的视图能够自动地得到通知；在一个视图中改变模型的属性，将导致模型其他的视图也随之更新。　　最后，由于模型独立于视图，所以，不需要修改模型来适应新类型的视图或控制器。 3.1.1 插入式视图和控制器 　　Swing(和AWT)容器把定位它们所包含的组件及确定这些组件的大小的工作委托给一个布局管理器。布局管理器封装了布局组件的策略。例如，FlowLayout布局管理器的策略是用组件的首选大小来安排组件的大小，并以从左到右、从上到下的顺序定位组件。　　封装的策略使它们是可插入的；例如，布局管理器可以在编译时，也可以在运行时刻插入到容器中。　　通过封装在视图中可视地表示数据的策略及封装控制器中处理事件的策略，MVC体系结构提供了可插入视图和控制器。就像布局管理器可以插入到AWT和Swing组件中一样，视图和控制器也可以插入到模型中。 3.1.2 视图更新 　　Swing(和AWT)事件由向事件源登记了的事件监听器来处理。例如，按钮的激活事件由一个对象所处理，这个对象实现ActionListener接口，并且通过调用这个按钮的addActionListener方法向这个按钮进行了登记（注：处理按钮动作事件的例子，请参见8.4节“JButton事件”）　　事件源和监听器是Observer样式的一个例子，Observer样式允许单个对象在所观察的对象修改时通知许多观察器。Observer样式需要在被观察对象与它的观察器之间有一个很小的接口区。例如，上面描述的动作监听器可以是任何类型的对象，只要它实现ActionListener接口。而且，按钮除了知道如何和何时通过观察器之外，对观察器一无所知。　　当模型改变时，MVC体系结构使用Observer样式来通知视图。模型可以有许多视图，所有的视图通常都用模型的通知来同步。而且，任何类型的视图都可以在不使模型本身有任务变化的情况下观察一个模型。　　图3-1示出了一个典型的MVC实现的信息流，并说明了在模型变化时，视图如何更新。　　事件由控制器处理，控制器根据事件的类型来改变模型或一个或多个视图。　　模型维护一个视图列表，这些视图为获得模型变化通知已经向模型登记过了。当模型发生变化时，该模型通知已向此模型登记的每个视图。视图通常从该模型中获得信息以进一步澄清这个事件，接着再更新它们自己。　　Swing提示　　MVC的优点　　很久以来，MVC体系结构一直是建立Smalltalk应用程序的基础。　　面向对象开发的最基础的方面是确认抽象并在类中封装抽象。例如，一个工资册应用程序可能确认雇员、工资等抽象。在类中封装抽象允许在对象间建立松散的联系，这样就减少了依赖性，增加了灵活性和再使用性。　　MVC封装了三个在大多数图形应用程序都存在的通用抽象：模型、视图和控制器。通过封装其他体系结构的优秀特性，MVC应用程序比相应的传统应用程序更灵活和更具有使用性。 3.2 Swing MVC 　　Swing MVC