精华区 [关闭][返回]

当前位置:网易精华区>>讨论区精华>>编程开发>>● 系统分析>>面向对象专题>>面向对象的系统分析与面向对象的可视化开(5)

主题:面向对象的系统分析与面向对象的可视化开(5)
发信人: 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: ]

[关闭][返回]