发信人: leeyg() 
整理人: leeyg(2001-06-05 22:19:18), 站内信件
 | 
 
 
你可以引用本文,但请注明作者,并请注明出自本论坛。     
                       请大家指正。     
 
 (五) 界面的继承问题
 
     既然界面的设计也用OO的思路,界面也是类,那么,界面之间的继
 承问题怎么实现?
 
     首先,我们来看看,界面是否需要继承。
 
 如上所述,界面是一个类,但由于每一个类都有不同的界面,一个系统
 中不会出现2个以上完全一样的界面,所以,界面是一种只有一个对象
 实体的特殊类,既如此,本人认为,没有必要从某个界面中派生出另一
 界面,换言之,界面不要考虑继承的好。
 
    另外一个原因,如果界面也考虑互相间的继承,那么被复用者的类
 树将会出现并将会很复杂,这又是另一个领域的系统分析与系统设计,
 所需花费的时间与可视化开发工具带来的便利完全抵消了,我们应该
 充分利用可视化开发工具的快捷、可视性来开发人机界面,尽可能避
 免被复用者的类树。
 
     但是,话说回来,相当于界面中属性的各种控件,倒是应该尽可
 能地从原有的控件中个性化的,如果Form是作为控件来考虑的话,也
 是如此。父类中继承并个性化出新的控件,应该视为是对被复用者的
 各个控件的补充,其文档也应列入被复用者中,而不是本系统中。
 
 (六) 界面类的合并
 
     一个界面最好只表达一种类,举例来说,“联系人通讯录”对应
 的界面,表达的是所有的已实例化联系人实体,界面上看到的主体应
 该是一个所有联系人关键资料的列表,没有必要在这人界面中将联系
 人实体的所有资料详细显示出现,真要显示联系人实体的所有资料时,
 可以双击列表中的某联系人,弹出“联系人”类对应的界面。
 
     但是,考虑这种情况,“联系通讯录”类的“增加”方法会触发
 一个“增加界面”,“修改”方法会触发一个“修改界面”,“删除”
 方法会触发一个“删除确认界面”,是否应该为每一个界面都设计一
 个Form,每一个Form中都有一个Ttable或Tquery来体现这个实例连接?
 
    应该说,这的确是一种清晰的解决方案,最原始的方法应该如此。
 但是,这种方法存在这些缺点:
 
     (1) Form的数量多,不易管理与维护;
     (2) 资源占用大,系统庞大;
     (3) 仅将可视化开发工具看成了纯粹的界面开发工具,没有充分
         利用其便利性
     (4) 忽略了系统(导航)界面。(通常就是如主菜单等引导用户
         操作的系统界面)
 
     让我们再来重新认识界面:如上所述,界面是多个控件的组成的可
 与用户交互的外观及控制。控制体现在各类按纽按键,可以将多个控件
 组成一个视觉外观的,除了Form类,还有最常用的Panel类。
 
     一个可行的方案是:由一个Form作为“联系人通讯录”的主界面,
 设计AddPanel作为“增加界面”,ModifyPanel作为“修改界面”,
 “DeletePanel”作为“删除确认界面”,三个Panel界面均存在于同一
 个Form中,作为Form的属性。
 
     这样处理,解决了上面所述的一类多Form的缺点,实现了一类一
 Form,避免了被复用树的生成,简化了OOD文档,使OOD文档清晰明了,
 将一个类的所有界面都封装在一个Form中,已经解决了属性、方法、
 界面、关系都封装在一个Form中了。
 
     更深层次地,这样的处理,正确解决了适应可视化开发工具的OOD
 与编码的界限问题,划分给编码员的工作(即Form的设计)已经完全可
 由编码员利用可视化开发工具独立开发。
 
     举例来说,对“联系人通讯录”,设计员通过分析得出:
     (1) Form中有一个数据库Ttable或Tquery,以实现类与界面的连
           接关系;
     (2) Form中必须有表达数据库各字段的相关属性,如Tedit,
           TDBEdit等;
     (3) Form中有“增加”、“修改”、“删除”等按纽,按动它
           们时,直接调用类中的Add、Modify、Delete等可由界面触
           发的方法;
     (4) Form中有AddPanel、ModifyPanel、DeletePanel三个分别
           代表“录入界面”、“修改界面”、“删除界面”的属性。
 
     有关Panel,在这里我们不将它看成一个控件,而将它看成一个界
 面的容器(如Form),那么,不必将AddPanel从Panel中继承而来,将
 相关的控件放上去组成界面即可,这样,最后一个问题也解决了!
 
     事实上,IBM的Lotus Notes的风格似乎就是这样实现的。
 
 七、人机界面的文档与OOD文档的结合
 
     好了,让我们回到初始的问题,怎样将OOD的文档直接交给编码
 员,OOD文档应该如何细化?
 
     通过以上的分析,OOD文档应该这样细化:
 
     (一) 判断OOD中的各类是否需要界面,如果需要界面,在类图
            的旁边再划一个类,将这个类定义为“某某(类)界面”
 
     (二) 判断这个类是反映的是已实例化对象实体的集合还是仅仅
            是反映一类对象的抽象模板,如是数据库,在“某某(类)
            界面”的属性栏中增加一个“实例化对象集合”属性,如
            仅仅是抽象模板,增加一个“某某(类名)”(如“联系
            人”);
 
     (三) 将OOD类中可由界面触发的方法,抄录一份在“某某(类)
            界面”的方法栏中;
 
     (四) 审核OOD类中可能存在的界面,在“某某(类)界面”的属
            性栏中加上相应的Panel;
 
     (五) 最后,在OOD类与“某某(类)界面”之间,划一条连接线, 
            连接线上写上“交互”,这就是它们之间的关系。
 
     文档细化到这个地步,其它的工作,已经完全可以利用可视化开发
 工具的便利解决了。这样,这份文档,已经完全可以进入编码阶段了。
 
     以上的思路,已经在一套系统中完整地实施,效果相当不错。本文
 只能将基本的思路提出来,在实际的应用中,还需要不断地实践,希望
 能多与各位交流。
 
 
 (完)
  -- ※ 来源:.月光软件站 http://www.moon-soft.com.[FROM: ]
  | 
 
 
 |