进销存软件之OO设计--中间层处理(二)

最新推荐文章于 2022-03-20 17:34:20 发布

wokagoka

最新推荐文章于 2022-03-20 17:34:20 发布

阅读量926

点赞数

分类专栏：业务管理文章标签： oo interface integer constructor 物流 function

业务管理专栏收录该内容

3 篇文章 0 订阅

订阅专栏

。。。接上文

另：参考图　请见上文

TbizProcess类

　　这个类是从TBaseBillobj继承下来的，如果说TBaseBillobj是用来处理业务单据的一般事务，那TbizProcess就是用来处理单据过账操作的，但是TBaseBillobj实际上只用几个Abstract Method来提供过账操作的’接口’而真正实现是由那些个TxxxBillobj的具体业务单据类来实现。请看下面讨论：

单据不仅要做保存更新这样的操作，还要有过账处理从而才能影响系统的库存和账务，最终才能从报表功能中表现这些影响，从而才能使用户得知当前业务的状况如何。基本上各单据的过账处理对账务的影响都是不同的，但大体可以归纳为钱流处理和物流处理，无论哪种单据最少都要执行这两个其中的一个，比如一张采购进货单处理后即会对系统钱流数据产生影响，而且对物流数据也产生影响，那么一张销货收款单只会对钱流数据产生影响，而销售订单即不会对钱流数据产生影响也不会对物流数据产生影响。于是对于不同的单据我们知道要进行钱流或物流的处理，但不知道具体单据类型之前，我们并不确定钱流或物流处理的具体内容，那么根据此特点，我们可以声明一个类TbizProcess(见图２,3)，它有两个Abstract的方法：MoneyProcess和GoodsProcess(见图3)，代表钱流处理和物流处理的动作名称，之所以是‘动作名称’即这里只声明接口(我用的是Abstract Method做为接口而并非Interface)，这样在具体单据处理子类的中”实现”这些Abstract Method后即可做‘具体动作’，另外PrepareProcess和FinishProcess也是如此，分别在处理前和处理后做一些准备和善后工作。TbizProcess类还有一个方法是ProcessFlow，调用它来实现整个过账处理，无论是什么单据处理都是使用如下ProcessFlow：

//业务单据过账处理：

function TBizProcess.ProcessFlow(BillHead:OleVariant; BillDetail:OleVariant; Tag:integer):

Integer;

Begin

。。。。。。。

FConnection.BeginTrans;

。。。。。。。

PrepareProcess;

GoodsProcess;

MoneyProcess;

FinishProcess;

。。。。。。。

。。。。。。

FConnection.CommitTrans;

。。。。。。。

End;

这里以MoneyProcess为例：

进货单是这样的钱流处理

procedure TBuyBillobj.MoneyProcess;

begin

with FBizProvider do

begin

BankProcess(-1);　//现金银行账务处理

ArApForBuy; //应收应付账务处理

StockGoods; //库存成本账务处理(并非库存变动处理)

end;

收款单的钱流处理内容与进货单不相同,依此类推…

procedure TGatheringBillobj.MoneyProcess;

begin

with FBizProvider do

begin

BankProcess(1);

ArApForGather;

end;

这样TbizProcess声明了接口(Abstract Method)，那下层的单据子类如:TbuyBillobj和TgatheringBillobj用统一接口实现不同操作内容。对于PrepareProcess; GoodsProcess;FinishProcess;也是一样的。这样无论子类的实现内容如何变化，调用程序都不被(或很少)受影响，因为有一至的接口。

注：可以用Abstract Method当做’接口’，但Interface更先进，特别是更复杂的情况下，VCL不少地方使用Abstract Method来当接口，但使用Interface好像是趋势(李维的<<Inside VCL>>中对Interface说明的相当的详细)，另外看看.net的framework，很多地方都使用Interface而不再是Abstract Method，特别是Ado.net。我使用Abstract Method的原因是当初的‘认识’问题以及系统并不巨大，而且当前所用的办法也工作的很好就是了。

TxxxBillobj类：

这是一系列具体单据处理类，xxx代表单据的英文名如TbuyBillobj,TsaleBillobj等，见图(4)。比如以下是销售单类的声明，它重新override了一些父类的方法以及实现了上面提到的4个抽象方法。其它TxxxBillobj的实现也都是基于这种思路。

TSaleBillobj = class (TBizProcess)

private

FBizProvider: TBizProvider;

public

function BillHeadCondition: string; override;

function DetailSql(optype:integer): string; override;

procedure FinishProcess; override;

procedure GoodsProcess; override;

procedure MoneyProcess; override;

procedure OrderCheck(cds:TClientDataSet); override;

procedure PrepareProcess; override;

end;

TbizProvider类：

上面提到可以把业务流的处理分为MoneyProcess和GoodsProcess，而钱流和物流处理实际上各自又包括一些具体内容，比如从上面进货单的钱流处理procedure TBuyBillobj.MoneyProcess;就可以看到总共有现金银行账务处理、应收应付账务处理、库存成本账务处理等，那么系统中像这些具体的处理功能有很多，用非OO的设计方法实现时可以写若干个通用的Function或Procedure达到目的，如果用OO实现，我考虑了两种方法，一个是从父类声明Abstract Method(如果基类有实现可以用Virtual Method)方法，然后到子类再做具体实现。第二种是写一个服务类或者说是工具类比如就叫它TbizProvider类，它提供这些现金银行账务处理、应收应付账务处理、库存成本账务等处理的实现，然后各业务单据子类再声明一个此类型的属性或是域(我这里用的域FBizProvider)来使用。如下：

参考上面TsaleBillobj类的声明中有FBizProvider: TBizProvider;

TbizProvider的细节见图３，另外TbizProvider的Create如下：

声明：

constructor Create(AOwner:TComponent;BizObj:TBizProcess); reintroduce; overload;

实现：

constructor TBizProvider.Create(AOwner:TComponent;BizObj:TBaseBillObj);

begin

inherited Create(AOwner);

FBizObj:=BizObj;　　

end;

这样TbizProvider在Create后将来就知道是为哪个业务单据做现金银行、应收应付等处理

如下为TsaleBillobj建立TbizProvider的实例：
procedure TSaleBillobj.PrepareProcess;

begin

。。。。

FBizProvider:=TBizProvider.Create(Self,Self);

。。。。

end;

procedure TSaleBillobj.MoneyProcess;

begin

with FBizProvider do //调用TbizProvider提供的一系列功能

begin

BankProcess(1);

ArApForSale;

SaleCost;

SaleIncome;

StockGoods;

end;

以上TbizProvider的Create中第二个参数为TbaseBillObj类型的对象，而传入的实际为它的子类型(TSaleBillobj)对象实例(self)，结合这样的处理方法正好也是OO中对多态的使用。(Overload那个Create与多态没有关系)，这样一来，在TbizProvider内部只知道有一个要被提供服务的’单据’(TbaseBillobj)就行了，具体是哪个单据(TxxxBillobj)不用知道，在TbizProvider的实现程序里使用那个FbizObj就可以了。