熬之滴水穿石：Delphi曾经的利器(4)

                                                                           8--VCL的设计模式

设计模式是我在搞JAVA编程时开始渐渐熟悉起来的，记得当时还特意看了四人组写的《 设计模式》一书。第一次看时收获不大，反而陷进了为模式写代码的窠臼。现在想想当时理解晦涩很大部分原因就是看不到实实在在的例子，所看到的都是一些与实际工作并不是有很大关系的代码。说白了就是一个纯理论的东西，当时的网络搜索远没有现在这般发达便捷，所以所看到的代码所获取的感受很是局限。回头看Delphi的底层代码时，发现了很多比较熟悉的写法。VCL还是用了不少的设计模式，以至于DELPHI的程序员的编码工作已经凌驾在模式之上了。好了，就单单VCL的代码，说说我对于设计模式的理解吧！当然这个模式是限于DELPHI，设计模式在以后的篇幅中，我还是会提到的。

在Delphi的组件时间里，我见到了组件之间是通过类似于观察者模式的一种设计方式，其主要原因组件类只见都是由Componet类派生下来的，所以各个组件之间的关系如何管理便是首当其冲的问题，所以当一个对象和其它对象互动时，能让对方知道每个对象的状态改变。基本思路是在 Component对象在创建的时候，就会用数据结构（一般都是用TList）将子类对象加入其管理的范围内，当Component在遇到析构时，实际上就采取一个叫Notification的方法，告诉相关的对象你需要free掉了。这些需要通知的动作，在VCL里一般都是用枚举类型来定义的。一般需要进行通知的母体必然是一个容器，像我们用到的Form对象它实际上就相当于是一个容器，而上面的button和text文本框等则都是被通知的对象。在容器对象中设计了一个 Notify的接口，容器在初始化时加载相关的类，然后确保当有事件触发时可以通知到所管理的各个类。

我在VCL的 TCollection和 TCollectionItem中曾看过该模式的代码，在与Notify的方法一般都定义为virtual方法了。这样相关的派生类可以增加各种需要通知事件的代码。

Delphi里有个控件叫 TACTION，这个控件就是由一种设计模式衍生而来的，这个模式便是命令模式（ Command）。这个模式的用途就是封装客户端发来的请求。在使用Action控件编程时我们就可以发现，所有的处理代码可写在Action里，而我们所触发事件的按钮只需要与相关的 Action的Exeute方法挂接起来便可完成功能。通常我们会在一个datamoudal中放置action控件，以实现请求的对象与客户端代码分离。这样一来，所有界面上请求的都是通过Action这个对象的方法来实现功能的，整个请求框架形成了一个完整的类架构。当然实现这个控件的方法显然比Command模式更为复杂起来。

在我编写MIDAS代码的日子里，我经常用到了 Data Provider控件。该控件是放在一个名为Remote DataModule的模块中，其实是在接受由Client端的调用，通过它去访问或操作相关的数据。后来我才发现，其实Data Provider控件本身就是一个很明显的设计模式--外观模式( Facade)。而与该控件相关的便是TDispatchAppServer类，这便是一个典型的Facade.在Data Provvider绑定的dataset里，实现了更多细节的代码。而作为Client端在调用方法时根本不需要考虑你是怎么用哪个dataset去存储数据去处理数据的。它只需要调用类似的方法便可完成任务，所以这种模式在分布式的系统很吃香！在短暂的EJB时代，SessionBean就是从这衍生而来的。在Delphi，这个外观类叫作IAppServer，它对外提供了一个一致的接口可以便于调用群组服务，它分离了客户端和服务端的依赖关系，像在C/S时代，客户端连接数据，就一定需要这种或者那样的设置，在客户端写这样或者那样的SQL语句，而这些对于外观模式来说，客户端根本无须知道。

其实在DLPHI中我觉得Table,Query等数据操作集控件都是非常强大并且很具有设计思想的类。像Table这样的控件其实就是用户在处理这个数据库表时，用Table这样的类去封装了这个数据表的类对象，再调用其中的方法来处理这个数据库表，这是多么伟大和强大的方法啊！这样让程序员不再自行编写复杂的代码来存储数据了。当然这些控件的实现并不想java中ibatis一样，它只是面向数据的，都是以数据处理为主的而非对象的，但这足以非常强大了。

                                                                          （未完待续...........）