最近感觉每天的实际工作时间并不是很多,也就是真正产生代码的工作时间并不是很多,想一个问题想太久会头疼,尤其是那么复杂的问题。只有当你面对真正的企
业级应用时,可能才会有这样的感觉,复杂而又变态。昨天那个叫做StockpilingDayInterval的类已经脱胎换骨了,哦,其实没有,我只是
进行了错误的重构,现在想来,似乎应该直接创建那两个对象FreeStockpilingDays(免费堆存时间,免堆期)和
FreeStockpilingTimeExtendedDayInterval。经过半个小时的编程和测试,这两个类已经变成POJO了。很显然
FreeStockpilingTimeExtendedDayInterval是从数据库中读出来的,而且是设定规则时设定的。而
FreeStockpilingDays则是通过规则计算出来的,这个规则就是这样的,条件表达式+结果表达式,看到我之前抽象出来的
ResultExpression接口的作用了,Rate继承了它,表示返回结果是费率,而现在应该用FreeStockpilingDays来继承它
吗?哦,那它将继承这个接口,那它就不是POJO了。
我现在设计的是将StockpilingDayInterval作为规则表达式项(它继承了
AbstractConditionExpressionItem抽象类,实现了ConditionExpressionItem接口),它可以根据免费
堆存时间和超期堆存时间段计算出用于匹配生产数据中的时间的时间段。我现在在测试里这样写:
//确定免堆存期
FreeStockpilingDays fsdi=new FreeStockpilingDays();
fsdi.setFreeStockpilingDays(6);
//确定超期堆存时间段
FreeStockpilingTimeExtendedDayInterval freeDaysExtended=new
FreeStockpilingTimeExtendedDayInterval("1~10",new Rate("3.5"));
//创建堆存时间段规则
StockpilingDayInterval sdi=new StockpilingDayInterval(fsdi,freeDaysExtended);
assertEquals("7~16",(String)sdi.getStockpilingDayInterval());
DefaultRuleExpression re= new DefaultRuleExpression();
ConditionExpressionComposite cec = new ConditionExpressionComposite();
cec.add(sdi);
re.addConditionExpression(cec);
re.addResultExpression(freeDaysExtended.getRate());
re.setId(1);
但是在客户端程序中,如何使用这段代码呢?一条规则的数据,来自于由另一条规则决定的数据,这里有点递归的意思,可惜我数学不好。
那好,先不递归,我来看看这里面的流程:
1 先是读取规则确定免堆期 [if gte mso 9]> Normal 0 7.8 磅 0 2 false false false MicrosoftInternetExplorer4 <!---->
Style Definitions table.MsoNormalTable {mso-style-name:普通表格;
mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0;
mso-style-noshow:yes; mso-style-parent:""; mso-padding-alt:0cm 5.4pt
0cm 5.4pt; mso-para-margin:0cm; mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New
Roman"; mso-fareast-font-family:"Times New Roman";
mso-ansi-language:#0400; mso-fareast-language:#0400;
mso-bidi-language:#0400;}<!---->
2
确定超期堆存时间段(对应费率),在这里将时间段+费率都给了这个对象,这与实际情况是一致的。
3
确定堆存时间段条件表达式(由免堆期和超期堆存时间段确定堆存时间段)
4
确定规则表达式(条件:堆存时间段条件表达式;结果:超期堆存时间段对应的费率)
5 然后将需要计费的数据与规则表达式匹配,成功即返回正确的费率。等等,目前好像不是这样的,匹配成功后,并不只是返回费率,而是进行相应的计算。
前四步实际上就是不断的从规则库和事实库(借用一下专家系统的概念)中取得规则和事实,然后最终生成一条规则表达式。那是不是该有个方法叫generateRuleExpression呢,那它又该是哪个对象的方法呢?好像这又是一个应用模板方法模式的地方。
总之这意味着生成规则表达式不是个简单的可以用同样的方法搞定的事情,这比我原先想象的又要更复杂了。
好了,先写到这儿,我现在很需要一个pair,因为感觉自己已经陷入到一种模式里面了。
或许是我的建模思路有问题呢?为何还是举步维艰呢?
分享到:
相关推荐
中国电信的计费模型数据模型是一套复杂而全面的体系,旨在有效管理和处理电信服务的计费、账务以及客户服务等多个方面。模型分为多个章节,包括产品域模型、客户域模型、定价域模型、计费事件域模型和账务域模型,...
《中国电信计费模型:功能与流程详解》 在电信行业中,计费模型是核心系统的重要组成部分,它负责处理用户的服务消费记录,计算费用,并生成账单。本文将深入探讨中国电信的计费模型,涵盖其主要功能、工作流程以及...
在中国电信的计费模型中,涉及的领域广泛且复杂,涵盖了多个关键环节,旨在确保服务的公正、准确和高效。计费模型不仅是电信运营商的核心业务系统之一,也是支撑其收入和客户服务的重要基石。以下是关于“中国电信...
1. **大数据技术**:随着通信技术的发展,大数据分析在计费模型中的应用越来越广泛,通过分析用户行为预测消费趋势,优化计费策略。 2. **5G时代的挑战**:5G网络的高速率和大连接数对计费系统提出了更高的实时性和...
### 中国电信计费模型_数据模型_0.8.6 #### 概述与编写目的 中国电信计费模型_数据模型_0.8.6是中国电信集团为了优化和完善其计费系统而制定的一个数据模型标准。该文档旨在为计费系统的升级与重构提供指导性框架...
《中国电信计费模型2.0-网管与监控》是中国电信集团在2005年至2007年间为提升其计费系统能力而推出的重要项目。该模型旨在改进和优化原有的计费流程,通过引入先进的网络管理和监控技术,确保计费的准确性和效率,以...
【中国电信计费模型】是中国电信运营中的核心组成部分,主要用于计算和管理用户的通信服务费用。BOSS(Business Operation Support System)是业务运营支撑系统,它在其中扮演着至关重要的角色,负责处理计费、账务...
为了验证所提出的浮动式停车计费模型的有效性和可行性,研究人员通过算例进行了实证分析。结果显示,在采用浮动式停车费率的情况下,路网的流量分配更加均衡,停车场的利用率也得到了显著提高。相比于传统的固定费率...
计费模型不仅涉及到用户消费的计算,还涵盖了账单生成、费用结算和数据分析等多个方面,是电信运营的关键环节。 第二章总体框架中,详细描绘了网络管理的整体架构。该框架包括了多个层次和组件,如网络设备监控、...
3. **计费模型分析**:云服务商如阿里云、AWS、Azure等提供了多种计费模型,如按需付费、预留实例、竞价实例等。理解并对比不同模型,选择适合业务需求的计费策略,能够显著降低成本。 4. **成本预算与监控**:设定...
为了提供更优质的云服务,电信运营商需要建立一个实用、先进的计费模型,能够精确记录用户的使用行为,及时反映消费情况。这包括但不限于以下几个方面: 1. **资源计量**:建立精细化的资源计量系统,能够实时监测...
【基于UML的网吧计费系统分析与设计】 UML(Unified Modeling Language)是一种标准化的建模语言,专用于面向对象的分析与设计。在设计和分析基于UML的网吧计费系统时,UML提供了多种视图来全面描绘系统的各个方面...
《数字电视用户计费系统的分析与设计》这篇文章深入探讨了数字电视计费系统的设计与实现,结合当前业务现状和未来发展趋势,旨在创建一个通用、灵活且支持多业务的计费模型。文章首先从计费系统需求分析入手,指出...
2. **计费模型**:计费模型是系统的核心,可能包含基于时间、用量、套餐等多种计费策略。例如,对于电话服务,可能根据通话时长计费;对于网络服务,可能按流量或固定月费计费。 3. **账单生成**:系统需要能够根据...