职责链模式+策略模式+反射+配置文件,完美实现下机操作(一)

纵观机房收费系统,逻辑最复杂的也就是下机操作了,这几天一直在考虑下机操作该如何进行。

流程分析:

  1. 判断卡号是否存在与是否上机
  2. 上机时间的处理
  3. 根据时间计算消费金额
  4. 更新余额,添加记录

关于逻辑的操作主要集中在两个计算上面时间和金额。首先说上机时间的处理问题,做之前我看了下第一版机房收费系统关于下机的操作:

           '计算消费时间

            TxtTime.Text =DateDiff("n", Trim(TxtOntime.Text), Trim(Offtime))

            TxtTime.Text = TxtTime.Text -preparetime

            If TxtTime.Text < 0 Then

                TxtTime.Text = 0

                TxtMoney.Text = 0

            Else

                 '计算消费金额

                    If Trim(TxtType.Text) ="固定用户" Then

                        TxtMoney.Text =Int(TxtTime.Text / 30) * Val(Trim(rate))

                        IfVal(((Val(TxtTime.Text) Mod 30) + 30) * 60) > Val(Trim(unittime)) Then

                            TxtMoney.Text =Val(Trim(TxtTime.Text)) + Val(Trim(rate))

                        End If

                       '---------------------判断上机时间是否大与30分钟,小于30分钟按30分钟收费

                        If Val(TxtTime.Text)< 30 Then

                            TxtMoney.Text =rate

                        End If

                    Else

                        TxtMoney.Text =Int(TxtTime.Text / 60) * Val(Trim(tmprate))

                        IfVal((Val(TxtTime.Text) Mod 60) * 60) > Val(Trim(unittime)) Then

                            TxtMoney.Text =Val(Trim(TxtMoney.Text)) + Val(Trim(tmprate))

                        End If

                       '---------------------判断上机时间是否大与60分钟,小于60分钟按60分钟收费

                        If Val(TxtTime.Text)< 60 Then

                            TxtMoney.Text =tmprate

                        End If

                    End If

            End If

            mrcLine.Close

真是惨不忍睹,时间处理不完善,一长串的if...else...语句,耦合过高,应对变化能力基本没有,别提维护和扩展性问题了。。

经过查阅资料和分析,决定对于上机时间处理这块采用职责链模式,因为上机的时间根据大小分为三阶段,准备时间、至少上机时间、单位递增时间,在判断处理的时候是依次进行的,这就与职责链模式(“加薪”模式)不谋而合了,参照加薪模式把三阶段写成三个类,准备时间类,至少时间类和单位时间类。传入上下机的时间,如果小于准备时间,则准备时间类进行处理,否则传入下一阶段;如果小于至少上机时间则,至少时间类进行处理,否则继续传;一直到能够处理为止。消除了大量的选择判断语句,这也正是职责链的职责所在。

UML图

相关代码(这些类都建在B层)

  1. BL_COR_TimeHandler  抽象类,定义一个处理请求的接口
PublicMustInherit Class BL_COR_TimeHandler

    Protected successor As BL_COR_TimeHandler

    PublicSub setsuccessor(ByVal successor As BL_COR_TimeHandler)                '设置继承者者

        Me.successor = successor

    End Sub

    Public MustOverride FunctionHandleTime(ByVal time As Integer) As Integer    '处理请求的抽象方法

EndClass
  1. BL_COR_PrepareTimeHandler继承类BL_COR_TimeHandler,准备时间处理类
PublicClass BL_COR_PrepareTimeHandler : Inherits BL_COR_TimeHandler

    Dim preparetime As Integer

    Public Sub New(ByVal ENBasicData As List(OfEN_BaseData_info))         '构造函数,传入准备时间的值 

        Me.preparetime =CInt(ENBasicData(0).preTime)

    End Sub

    Public Overrides Function HandleTime(timeAs Integer) As Integer

        If time <= preparetime Then                  '如果上机时间小于准备时间,返回0 

            Return 0

        Else

            Returnsuccessor.HandleTime(time)       '否则转到下一位继承者 

        End If

    End Function

EndClass
  1. BL_COR_LeastTimeHandler,至少时间处理类
PublicClass BL_COR_LeastTimeHandler : Inherits BL_COR_TimeHandler

    Private leasttime As Integer

    Public Sub New(ByVal ENBasicData As List(OfEN_BaseData_info))         '构造函数,传入至少上机时间的值 

        Me.leasttime =CInt(ENBasicData(0).leastTime)

    End Sub

    Public Overrides Function HandleTime(timeAs Integer) As Integer

       If time <= leasttime Then                  '如果上机时间小于至少上机时间,返回时间

            Return leasttime

        Else

            Returnsuccessor.HandleTime(time)        '否则转到下一位继承者 

        End If

    End Function

EndClass
  1. BL_COR_UnitTimeHandler 单位时间处理类
PublicClass BL_COR_UnitTimeHandler : Inherits BL_COR_TimeHandler

    Private unittime As Integer

    Public Sub New(ByVal ENBasicData As List(OfEN_BaseData_info))         '构造函数,传入递增时间时间的值 

        Me.unittime =CInt(ENBasicData(0).unitTime)

    End Sub

    Public Overrides Function HandleTime(timeAs Integer) As Integer       '大于至少时间,返回实际消费时间 

        Return Math.Abs(Int(-time / unittime))* unittime

    End Function

EndClass
  1. 到这职责链模式基本上就完成了,当然为了便于调用还可以添加一个类,类似外观的接口,调用的时候只需要传入两个实体参数就可以了。
PublicClass BL_COR_OnlineTimeCount

    ''' <summary>

    ''' 职责链处理,上机时间的计算

    ''' </summary>

    ''' <paramname="ENBaseDatainfo">EN_BaseData_info基本数据实体</param>

    ''' <paramname="ENLineinfo">EN_Line_info上机记录实体</param>

    ''' <returns>处理后的上机时间</returns>

    ''' <remarks>牛迁迁2014年7月2日</remarks>

    Public Function CostTime(ByValENBaseDatainfo As List(Of EN_BaseData_info), ENLineinfo As EN_Line_info) AsInteger

        '实例化类,通过构造函数,传递参数

        Dim bPrepareTime As NewBL_COR_PrepareTimeHandler(ENBaseDatainfo)

        Dim bLeastTime As NewBL_COR_LeastTimeHandler(ENBaseDatainfo)

        Dim bStepTime As NewBL_COR_UnitTimeHandler(ENBaseDatainfo)

       bPrepareTime.setsuccessor(bLeastTime)                 '设置职责链继承者

        bLeastTime.setsuccessor(bStepTime)

        Dim time As Integer                          '计算上下机时间差

        time = DateDiff("n",ENLineinfo.onTime, ENLineinfo.offTime) + DateDiff("n",ENLineinfo.onDate, ENLineinfo.offDate)

        ReturnbPrepareTime.HandleTime(time)          '职责链处理,返回上机时间

    End Function

EndClass
  1. 调用以及传入参数
'调用查询基本数据函数,返回实体集合

        basedatalist =queryBasedata.queryBaseData(ENBaseDatainfo)

        '调用职责链模式,计算上机的时间

        ENLineinfo.consumeTime =onTimeCount.CostTime(basedatalist, ENLineinfo)

应用职责链模式,使系统在应对变化上迈出了一步,如果机房要添加一个满3小时赠1小时活动的话,只需要添加一个相应的时间处理类即可,很好的符合了开闭原则。

时间的处理就介绍到这,下篇博客会介绍如何根据时间自动计算出消费的金额(策略模式+反射+配置文件的应用)。

未完待续。。。

职责链模式+策略模式+反射+配置文件,完美实现下机操作(一)

时间: 2024-07-29 21:36:23

职责链模式+策略模式+反射+配置文件,完美实现下机操作(一)的相关文章

设计模式-行为型模式-策略模式

策略模式 在实际工作中我用到了策略模式,但为什么要有环境角色呢? 这里我贴上英文对含义的介绍, The Strategy Pattern defines a family of algorithms,encapsulates each one,and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it. 然后看看这种设计模式的组成, 一般的,策略模式

第23章 行为型模式—策略模式

1. 状态模式(State Pattern)的定义 (1)定义:定义一系列的算法,把它们一个个封装起来,并且使它们可相互替换.本模式使得算法可独立于使用它的客户而变化. ①算法是同一接口的不同实现,地位是平等的,可以相互替换. ②引入上下文对象,可以实现让算法能独立使用它的客户.因为这个对象负责持有算法,但不负责决定具体选用哪个算法,把选择算法的功能交给了客户. ③当客户通知上下文对象执行功能的时候,上下文会转调具体的算法. (2)策略模式的结构和说明 ①Strategy:策略接口,用来约束一系

设计模式笔记:状态模式&amp;策略模式

这几天一直在忙期末考和实训,写笔记的时间也没有多少,不说废话了: 这文主要写两种模式:状态跟策略,主要是因为他们的类图一样,并且比较简单,写在同一篇文章里面容易甄别 状态模式:允许对象在内部状态改变时改变他的行为,对象看起来好像修改了他的类 先保留概念的意思,在平常的编程中,如果需要不同的状态,很一般的做法是在你要操作的类里面定义不同的常量代表不同的状态,然后if-else依据不同的状态有不同的实现: 1.你可以想象大量的if-else语句造成的低可读性和低效率 2.其次是你修改这个类的时候很麻

命令模式 &amp; 策略模式 &amp; 模板方法

一.策略模式 策略模式:封装易变化的算法,可互相替换. GoF<设计模式>中说道:定义一系列算法,把它们一个个封装起来,并且使它们可以相互替换.该模式使得算法可独立于它们的客户变化. 比如:一个推送服务类,推送的方式,可以分为:QQ推送.邮箱推送.App推送.PC插件推送. 这里讲两个点: 1.推送方式可以互相替换: 2.这些推送方式只是单纯的属于推送服务这个类本身. 好好琢磨关键词:相互替换 二.命令模式 命令模式:解决“行为请求者”与“行为实现者”通常呈现一种“紧耦合”的问题. GoF&l

19 行为型模式-----策略模式

模式动机(Strategy Pattern):在完成一个任务时可能有多种方式,具体使用哪种方式最有效,需要视条件而定,不同条件下所选择的策略也有所不同,这就需要在一个环境中对当前的情况做出各种判断,在程序设计中表现为分支结构的实现,即在一个环境类中通过不同分支来决定使用哪种策略,这种将实现策略与当前环境都封装在一个类中的设计方法称为硬编码. 硬编码有如下缺点:其一,如果环境发生改变需要增加条件判断时,需要修改当前环境类以增加分支:其二,在实时性方面,也许客户不愿意支持它们不需要的分支算法,因为分

Android中设计模式--策略模式(封装会变化的算法部分,面向接口不针对实现)

策略模式:定义了算法族,分别封装起来,让它们之间可以互相替换,此模式让算法的变化独立于使用算法的客户. 理解: 把代码中类似,但又有差异的算法部分,提取出来,定义一个借口,不同的算法来进行不同的实现,但调用算法的客户可以进行统一的调用,因为实现了共同的借口,客户不需要知道具体的实现,而是知道怎么用,即针对接口编程,而不针对实现编程. 总结: 找出代码中可能需要变换之处,把它们独立出来,不要和那些不需要变化的代码混在一起. 例子 private TextClickInterface mClickI

java设计模式--行为型模式--策略模式

策略模式: 1 策略模式 2 概述 3 定义一系列的算法,把它们一个个封装起来,并且使它们可相互替换.本模式使得算法可独立于使用它的客户而变化. 4 5 适用性 6 1.许多相关的类仅仅是行为有异.“策略”提供了一种用多个行为中的一个行为来配置一个类的方法. 7 8 2.需要使用一个算法的不同变体. 9 10 3.算法使用客户不应该知道的数据.可使用策略模式以避免暴露复杂的.与算法相关的数据结构. 11 12 4.一个类定义了多种行为,并且这些行为在这个类的操作中以多个条件语句的形式出现. 13

行为型模式---策略模式

1.作用 一个类的    行为或其算法    在运行时   更改: 在有多种算法相似的情况下,使用 if...else 所带来的复杂和难以维护: 2.何时使用 一个系统     有许多许多类,而    区分它们的只是    行为: 3.如何解决 将这些算法封装成一个一个的类,任意地替换: 4.案例 诸葛亮的锦囊妙计,每一个锦囊就是一个策略: 旅行的出游方式,选择骑自行车.坐汽车,每一种旅行方式都是一个策略: 5.注意事项 一个系统的策略多于四个,就需要考虑使用混合模式,解决策略类膨胀的问题: 原

机房合作——职责链+策略模式

</pre><p><span style="font-size: 24px;">这两个模式在进行个人重构的时候也使用了,当时是懵懵懂懂的,现在合作中又使用了一遍,思路清晰了很多,感觉这些设计模式之间有千丝万缕的联系,功夫还不到家还得慢慢的理一理,记得有个师哥说过"到最后会发现设计模式其实就一个",所以努力吧!先看看这两个模式的应用.</span></p><p><span style=&qu