发信人: fanpb()
整理人: edison(1999-11-24 07:11:11), 站内信件
|
的确，在把开发转向oo之初，面临了许多的问题。那时OO只是一句
口号。什么是OO，怎样封装，怎样继承，怎样重载只具有例子级的经
验。真到实际产品的开发中，还是感到茫然。经过开发多个OO版本的
基础类库的摸索，终于找到一条适合本公司产品开发的OO方法。供参考。
1、要自顶向下分析数据关系，把数据分解成多个实体。特别强调，
一个实体不一定是一个表，而可能是一个表的组合。例如单据，我们
的数据库严格遵守二范式，所以肯定是一个总单细目。有的单据的细目
还有明细，一个实体由三个联的表组成:
一个单据实体：
总单：日期、客户...
细目：商品、数量、单价、库房...
明细：货位，状态，数量
我们设计数据库必须保持数据的完整性、一致性。所有，这三个表
必须看成一个实体。在任何一次commit时，必须保证数据完整一致。这样
就跟edison的想法略有不同。封装时只能将三个表的逻辑全部封装，而不
能分别封装。
2、大量使用继承。软件几百个功能中，只有两个功能例外（系统管理），
其它功能全部使用继承。
如何继承，曾使我们走了不少弯路。一段时间，认为OO应结合系统设计，
由商业逻辑导出OO设计。例如把OO设计为***流程等，最终找出一条结合OO，
从需求分析到系统设计的方法论。但深入下去，因水平太低，根本走不
通。不好意思：后来把OO由战略级下调为战术级。就是让OO起提高开发效率、
方便维护的纯技术作用。
经过分析，我们的软件功能无非这么几种：
1）单表编辑。就是一个表格(grid)Datawindow。有时有卡片datawindow(Fr
eeform)。
2)总单细目。两个表格Datawindow，并且要严格维护对应关系。
每个Datawindow都可能有一个FreeForm Datawindow编辑。
3)总单细目+明细。三个表格Datawindow。
每个Datawindow都可能有一个FreeForm Datawindow编辑。
4)其它变形，如单表编辑加一个树形控件显示层次结构。
经过以上分析，发现不管商业逻辑多么复杂，都最终体现在功能上。而功能
跑不出以上几种形式。于是下大力气，做好这几个功能的基类（都是uo)。每个u
o
内嵌1-n 个Datastore做为数据存取对象。如果需要编辑，打开编辑窗口，让
datastore和窗口上的datawindow sharedata。
最后再辅以PBORCA.dll调用，自动生成一个功能继承后的对象。这样在做好
Datawindow的前提下，只要输入参数，就能完成一个功能最基本的开发。不需要
写
写一个字节的代码，有些功能确定这样做的。但大多数功能还要重载事件函数，
如
相互调用等。
最终的目标是：让开发人员从大量的技术细节中脱离，集中精力于商业逻辑
的
实现。并且相对容易维护。基类对了大家都对，基类错了大家都错。
--
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.106.4.9]
|
|