.NET初学者架构设计指南（二）OO设计初次见面

系列文章导航：

.NET初学者架构设计指南（一）Hello world的时代

.NET初学者架构设计指南（二）OO设计初次见面

.NET初学者架构设计指南（三）设计模式

.NET初学者架构设计指南（四）Model-View-Controller

Entry是一个枚举类型，代码如下：

public enum EntryType
{
    Deposit = 1,
    Withdrawal = 2,
    Penalty = 3,
    Present = 4
}

　　下面的界面显示的就是刚才那个账户的账目。要显示这个界面只需要调用Account的GetEntrees方法，得到所有的账目，然后按时间顺序显示出来。这个界面上的消费情况就明确多了，用户很容易弄明白某个缴费是在哪几个月份被消费掉的。

　　并且，发票上的那几个一直搞不明白的数值也有了答案。比如2005年6月份的发票，我们先看看2005年6月份销账的所有账目（第六行、第八行），这两次一共扣除73.66元，这个金额就是本次消费；两次扣除之间存入200元，这个就是本次实缴；第五行的结余是17.66元，这就是上次结余；第八行上的结余是144元，这个就是本次结余。

　　用户检查了这个设计，觉得这样的费用显示明确多了。尽管一些措辞不符合习惯的业务词汇，但是他们的概念都是符合的。并且上次还有一个需求没有说：有时候需要把多个月份的发票合在一起打印。按照这样的账目表达方式，合并的发票数值也比较容易搞清楚了。明确了这样的对象关系，实现这个需求其实很容易。

　　面向对象的设计就是要这样，不要急于确定系统需要做哪些功能点和哪些界面，而是首先要深入的探索需求中出现的概念。在具体的流程不甚清楚的情况下，先把这些概念搞清楚，一个一个的开发出来。然后只要把这些做好的零件拿过来，千变万化的流程其实就变得很简单了，一番搭积木式的装配就可以比较轻松的实现。

　　另一个重要的类型也渐渐清晰的浮现在我们的眼前：账单（Bill）。他的代码片段如下：

Code
public class Bill
{
    public DateTime GetBeginTime()
    {
        //返回账单周期的起始时间
    }
    
    public DateTime GetEndTime()
    {
        //返回账单周期的终止时间
    }
    
    public Fee GetFee()
    {
        //返回账单的费用
    }
    
    public float GetPenalty()
    {
        //返回账单的滞纳金
    }
    
    public void CaculatePenalty()
    {
        //计算账单的滞纳金
    }
    
    public float GetPaid()
    {
        //返回已支付金额
    }
    
    public float GetDebt()
    {
        //返回欠费
        //账单费用加上滞纳金，再减去支付金额，就是欠费
        return GetFee().GetValue() + GetPanalty() - GetPaid();
    }
    
    public Entry GetEntrees()
    {
        //返回相关的存入和支取的账目
    }
    
    public Bill Merge(Bill bill)
    {
        //合并两个账单，返回合并后的账单
        //合并后的账单可以打印在一张发票上
    }
}

　　Bill类有两个与滞纳金有关的方法，这使开发者想到了原先忽略的一个流程：计算滞纳金。经过与电信公司的确认，决定每个月进行一次计算滞纳金的工作。开发人员写了一个脚本，先得到系统中所有的欠费账单，然后一一调用他们的CaculatePenalty方法。每个月将这个脚本执行一次，就可以完成滞纳金的计算工作。

　　Bill对象中有账户的基本属性和各级账目的金额和销账的情况，要打印发票，只有这些数值是不够的。还要涉及到上次结余、本次结余和本次实缴，这三个数值是需要从账目中查到的。并且发票有严格的格式要求，也不需要显示费用的细节，只要显示一级和二级的费用类就可以了。应该把这些东西另外封装成一个类：发票（Invoice）：