我想我已爱上你——下机策略+职责（三）

       话说今天又是礼拜四，说实话我很喜欢这一天。为什么呢？睡懒觉？看电视剧？逛街？其实都不是。最主要的就是奔波了一个礼拜，终于有个时间可以闲下来，坐在电脑旁边，静静的回想着这一周所做的事情。回想着自己要总结的知识点。不知道什么时候，我就喜欢了在周四尽情的总结，没有紧迫感，没有压力。只是坐在这里静静地抒写着属于我的博客，梳理着我的收获，分享着我的想法。

       8月9号  天气：晴（不确定了），心情大好

       上周三经过艰苦的抉择，完成了策略模式，但是 在策略模式中，固定用户和临时用户的算法过程很相似，我先把过程写完，实现了功能之后，然后开始想怎么去优化。换做谁，谁都不想去写重复的代码。突然发现只有懒人才会做出出色的代码，出色的软件。因为他很懒。

        之后我就看看设计模式，然后就感觉职责联应该可以用上。那么职责联是什么呢？

       职责联说白了就是，别人提出要求，更具要求的具体内容不同，就会产生不出的做法和工作。使用职责联，只需要就是客户提出要求以及具体内容（参数），这个要求会沿着联进行传递，直到有一个条件来符合他。对方不了解对方怎么处理的，只是做好自己的工作就Ok。这样简化对方的互相连接，降低了耦合度。

下机为什么能够适合用职责联呢？

          首先我们来看一张Uml图（以固定用户下机结账为例）

        这个也就是再说，我客户端的固定用户要下机，要结账。结账根据上机时间进行结账，用职责联的方法，将这个结账写一个借口（onlieTime）,其中实现接口中德有三个子类，都是根据时间段进行划分的。如果请求符合Pre这个条件，就进行处理，如果不符合就要准发给他的后继者，在不符合继续向后转发就Ok。

代码是如何实现的：

B层：

outlineChine类

'' <summary>
'' 职责联模式
''设计人：李雪
''目的：将上下机的时间段分成一个一个的职责，减少彼此之间的耦合
''固定用户，临时用户的前两阶段的额算法是一样的，但是大于最小消费时间的算法是不同的，只是查在一个参数。
'' </summary>
'' <remarks></remarks>
Imports Entity

'抽象出一个联的抽象类（接口）
Public MustInherit Class outline
    Protected consume As Double
    Protected name As String
    Protected countMath As outline

    '初始化联的名称
    Public Overloads Sub outline(ByVal name As String)
        Me.name = name
    End Sub
    '设置链条关系
    Public Sub countMathLine(ByVal countMath As outline)
        Me.countMath = countMath
    End Sub
    '申请请求
    Public MustOverride Function CountTye(ByVal outlinetype As outlineType, ByVal data As BasicDataEntity) As Double

End Class

'继承抽象类，并且实现抽象类中德方法
'消费时间下于准备时间
Public Class PreTime : Inherits outline

    '得到自己的名称
    Public Overridable Sub preTime(ByVal name As String)
        Me.name = name
    End Sub

    '重写父类中的方法
    Public Overrides Function CountTye(outlinetype As outlineType, ByVal data As BasicDataEntity) As Double
        If (outlinetype.count <= data.perTime) Then
            consume = 0
        Else
            '如果田间不符合就转向下一级的方法中
            If (countMath IsNot Nothing) Then
                consume = countMath.CountTye(outlinetype, data)

            End If
        End If
        Return consume
    End Function
End Class

'消费时间间在准备时间和最少消费时间之间
Public Class PreToMin : Inherits outline

    Public Overridable Sub preToMin(ByVal name As String)
        Me.name = name
    End Sub

    Public Overrides Function CountTye(outlinetype As outlineType, ByVal data As BasicDataEntity) As Double
        If (data.perTime < outlinetype.count And outlinetype.count < data.minTime) Then
            consume = data.minMoney
        Else
            If (countMath IsNot Nothing) Then
                consume = countMath.CountTye(outlinetype, data)

            End If
        End If
        Return consume
    End Function
End Class

'消费时间大于最小消费时间，并且是固定用户的
Public Class FoutMin : Inherits outline

    Public Overridable Sub FoutMin(ByVal name As String)
        Me.name = name
    End Sub
    Public Overrides Function CountTye(outlinetype As outlineType, ByVal data As BasicDataEntity) As Double

        If (outlinetype.count > data.minTime And outlinetype.type = "固定用户") Then
            consume = (outlinetype.count - data.perTime) / data.increasingTime * (data.FixedperMoney / 60 * data.increasingTime)
            'cash = (spentTime - PreTime) / increasingTime * (FixedperMoney / 60 * increasingTime

        Else
            If (countMath IsNot Nothing) Then
                CountTye(outlinetype, data)
            End If

        End If
        Return consume
        Exit Function
    End Function

End Class

'消费时间大于最小消费时间，并且是临时用户
Public Class ToutMin : Inherits outline

    Public Overridable Sub ToutMin(ByVal name As String)
        Me.name = name
    End Sub
    Public Overrides Function CountTye(outlinetype As outlineType, ByVal data As BasicDataEntity) As Double

        If (outlinetype.count > data.minTime And outlinetype.type = "临时用户") Then
            consume = (outlinetype.count - data.perTime) / data.increasingTime * (data.TemPerMoney / 60 * data.increasingTime)
            'cash = (spentTime - PreTime) / increasingTime * (FixedperMoney / 60 * increasingTime)
        Else
            If (countMath IsNot Nothing) Then
                Return countMath.CountTye(outlinetype, data)
                Exit Function
            End If
        End If
        Return consume
        Exit Function
    End Function

End Class

outlineType类

Public Class outlineType
    Private _type As String
    Private _count As Double

    '说去用户类型的属性
    Public Property type As String
        Get
            Return _type
        End Get
        Set(value As String)
            _type = value
        End Set
    End Property

    '获取用户消费时间的属性
    Public Property count As Double
        Get
            Return _count
        End Get
        Set(value As Double)
            _count = value
        End Set
    End Property


End Class

FixedCoumers类

Public Class FixedCustomer : Inherits consume

    '计算消费的时间，消费的金额 同时更新到数据库中
    Public Overrides Function coutMoney(ByVal cardcon As CardConsume, ByVal type As String) As Double
        '定义一个消费时间的变量
        '用到查询基本数据中德数据，所以初始化一个basicDataEntity对象
        '分别将职责联中德三个类，初始化一个对象

        Dim spentTime As Double
        Dim basicdata As New BasicDataEntity
        Dim Rbasicdata As New BasicDataEntity
        Dim pre As New PreTime
        Dim pretomin As New PreToMin
        Dim foutMin As New FoutMin
        Dim count As New outlineType
        Dim bll As New CardBLL

        '然后设置职责联上家与下家
        pre.countMathLine(pretomin)
        pretomin.countMathLine(foutMin)

        '获取基本数据中德数据
        Rbasicdata = bll.GetBasicData(basicdata)

        '获取消费时间
        spentTime = bll.InOnlineStime(cardcon).spentTime

        '将获取的用户类型值和用户消费时间值传给outlinetype的一个实例化的对象中
        'outline实例化的这个对象主要就是获取数据写入数据，是职责联三个类计算的参数
        '也就是说给参数传值
        count.count = spentTime
        count.type = type

        '返回值
        Return pre.CountTye(count, Rbasicdata)
       
    End Function
End Class

        这些便是在B层中的策略模式+职责联模式。模式不是单独存在的，根据需要我们会选择模式套用模式。当然初次用这么用，也是第一次将学过的模式应用到实践中，很多的地方需要改进。

        这次在运用的时候就发现了一个问题：什么时候用职责联。根据我在写客户端这个代码的时候，就自己的小总结就是：选用职责联要符合一个递进的原则。层层递进，从而有了一个对象处理不了会转发给他的后继承着。同时职责也透露这这样的一层含义。
       职责：所在职位的工作任务和责任。一个公司的老板和一个小科长的职责肯定是不一样的。所以如果公司有人有个调薪的请求，根据薪水的多少，一层一层向上汇报，直到有一个人能够处理的。

       职责联的好处缺点是什么：我认为最大的好处就是灵活，解耦合，符合开闭原则。如果我还有个时间段，那么我只需要在加上一个类就Ok了，扩展性好。但是如果我的请求到了最末端都不能解决，那么请求得不到正确的解决，这样就有些糟糕了。所以任何模式都有利有弊，而我们就是要想办法利用好的一面，同时避免坏的一面的发生。

        这次的代码中还有一个不足之处就是：最后固定用户和临时用户的消费时间都大于最少消费时间，这两个算法的等级是一样的，只不过就是传递的用户类型的参数不一样，这样用职责联合适吗？根据我自己的想法就是，服从大众，既然大部分是这样的，极其一小部分另类，那么就让这一部分从了吧！