.NET初学者架构设计指南(三)设计模式

 

在上一篇里面,我们初步了解了OO设计,OO设计的最独特之处在于他看待需求的方式。用这样的方式,我们不需要急于确定软件需要实现哪些流程、设计哪些功能点、制作哪些画面,而是要关注需求中一些更加基本的概念。首先根据这些概念开发出一些零件,然后把这些零件组装起来实现需要的功能。用这样的方式,我们不需要一开始就去知道所有的业务需求,只需要知道一些比较重要的需求,就可以开始开发了。这样开发出来的程序不仅可以实现当前的需要,同时也是一个业务开发的平台,在这个平台上可以不断的开发新的功能。

这种设计思想有很多实际的例子,比如Microsoft Office。下面的图就展示了Excel里面最基本的几个对象:

Excel的各项功能都是建立在这个对象模型基础上的。比如要实现设置字体的功能,就可以这样编写:先打开一个字体对话框,使用者选择字型、字号,然后把这个字体设置到区域上:

 

Font font = CommonFontDialog.ChooseFont();
Application.ActiveWorkbook.ActiveSheet.Range(
"A1").Font = font;

Excel还把这些对象的引用暴露给了脚本引擎,于是我们就可以使用VBA调用他们,实现我们自己想要的各种功能,这就是Office宏。我们可以编写一段VB脚本,把鼠标选中区域的单元格复制到另一个工作表中,然后把某一个的单元格的值赋值为一个公式,计算出我们需要的数值。Excel不仅本身是一个好用的制表工具,他更是一个强大、易用的开发平台。使用者可以随时根据自己的想法,开发出需要的功能。一些大型的软件系统都是具有这样的特点,一开始就明确所有的功能需求是不可能的,重要的是形成一个业务开发的平台,提供一些业务编程接口,在这个平台上就可以不断的开发出新的功能。这样的开发方式不使用OO设计是很难实现的。

软件的第一个维护者和第一个使用者就是开发者本人,因此,开发迅速、功能灵活、维护简单——这些特点在精心设计的软件中经常是同时具有的。

运用OO方法设计程序的时候会遇到的这样困难:我们从需求中发现了一些模糊的概念,但是怎样才能根据这些概念建立合理的对象模型呢,到底哪些概念应该是一个类,哪些概念只应该是一个方法和属性,这些类之间应该是什么样的关系?要解决这个问题,最根本的途径当然是尽量深入的了解需求(比如说翻翻会计原理,看看应收款未收和已收的时候应该如何记账,其中一个记账原则也许就是一个重要的对象;协助用户做一个供电方案,随手画出的草图,或者某个计算公式就是一个重要的对象)。在解决了一个个困难之后,有人总结了经验,形成了一些解决特定问题的固定套路,这样的套路就是设计模式。

有些设计模式和OO没有什么必然的关系,比如层次模式,消息模式。但是大部分设计模式都是在OO设计中形成的,这些模式可以帮助我们发现系统中的对象、设计对象之间的关系。了解这些模式可以帮助我们把软件设计的更加合理。并且,在探索需求的过程中,我们也可以从模式中得到一些启发,获得设计的灵感,发现需求的真实面貌。

在上一篇我们看见了“费用”这个类型:Fee,其实这就是一个简单的设计模式:组合模式(Composite)。这个类的结构如下:

Fee类型是他本身的一个聚合,可以使用GetChildren方法得到某个费用包含的其他费用。如果一个费用没有包含其他费用,他的金额就是由他自己确定的,否则就是由他包含的费用相加确定的,这两种情况对外界提供的都是相同的方法:GetValue。这样,我们想显示一个账单费用的时候,不用再去判断他是否包含了其他的费用,调用起来就简单了很多。组合模式很好的体现了账单费用的层次包含关系。

刚才的情况里面,聚合类和元素类都是同样的类型。也有些情况他们分别属于不同的类型。比如一个企业,他的营销网络是由下面一些元素组成的:公司,市场部,直销店,代理商,自由代理人,营业员。如同下面的情况:

公司按照行政区域建立了多个市场部,市场部建立了自己的直销店,同时也与很多代理商和独立代理人进行合作,直销店和代理商雇用了营业员。每天公司需要对每个销售网点的情况进行查询和分析,需要知道他们定下了多少订单、收了多少货款、发展了多少新的客户。

这是一个比较复杂的结构关系,网点类型比较多,他们的销售方式差异很大,各类数据统计的方式也不同。并且在统计一些数值的时候,需要把下属网点的数量加起来,再加上自身的数量。如果采用组合模式,就可以解决这种问题。

我们可以设计一个类,叫做销售单位(SaleUnit)。这个类是他本身的一个聚合,可以通过一个集合成员访问到他下属的单位。并且他的每一种下属单元也是SaleUnit的子类。各种销售网点统计数据的方式是不同的:有的数据保存在数据库表里面,经过一些统计运算可以得到;有的直接放在数据表的某个字段里面,直接查出来就可以了;还有的是每天发过来的一个Excel电子表格。对于每一种不同的销售网点,都可以使用一致的接口对他们进行访问,得到需要的数据。

组合模式可以很精确的反映销售网点间的聚合关系,并且对查询和统计提供了非常一致的接口,调用者不必区分具体的网点类型。类似这样的情况,当我们发现需求中一些对象具有聚合关系,并且我们希望对他们做一些共同的事情,就可以采用组合模式。

现在产生了一个严重的问题:是的,调用一个对象的确实没有必要去区分具体的网点类型了,但是他们是在哪里被创建的呢,创建的时候还是要区分网点的类型,复杂的代码只是从一个地方转移到另一个地方罢了,这样做有什么好处呢?为了解释这个疑问,下面会介绍另一个常见的模式:工厂模式(Factory)。

工厂模式用来彻底的断绝调用者和被调用的具体类型之间的关系,他使用一个工厂创建具体的类型,调用者从工厂中取得对象的实例。调用者既不需要知道对象是怎样被创建的,也不需要知道创建的是什么类型。下面通过一个例子说明一下工厂模式的用处。

这是一个电气设备监控系统,他的一个任务是从安装在各处的传感器上采集各种设备的运行数据,集中显示在监视器上。还可以在设备上定义告警条件,当采集到的数据满足告警条件的时候,向监控人员发出告警,监视器上显示告警标志。基本的情况是这样的:

一个设备上可以有多个信号,比如一个变压器,上面可以有电压、电流、冷却剂温度等各种信号,分别由不同的传感器采集。每个信号隔一段时间会采集到一个数据,有的数据是直接采集到的,另一些是根据多个信号的情况计算出来的(比如一个电网环路上有n个节点,我们已经知道了其中n-1个节点的电压,就可以计算出最后一个节点的电压),还有的数据是一个推测值(需要根据一些经验数据进行推测)。传感器采集到信号数据以后,程序要判断这个数据的值,有时还要结合其他的信号,判断是否满足告警的条件,发出告警。

数据采集是一项十分复杂的工作,需要监控的设备种类繁多,数据意义复杂,传感器的通信方式也不相同。好在用户已经建设了了一个综合采集系统,解决了设备的实时数据采集工作。综合采集系统与各种传感器进行通信,将采集到的实时数据不断的输入到一个数据表里面。下面就是这个表里面的一些数据:

有了这么一个系统,直接采集数据的问题算是解决了。但是不同的信号类型对这个数据的解释仍然是不同的,我们仍然要应付这个问题。粗略的划分一下,有下面三种信号:

1、模拟信号:从综合采集系统里面查到实时数据,然后加上一个单位(比如伏特、安培),就可以显示了;

2、状态信号:需要定义一个状态描述。比如一个开关,采集数据高于0的时候就是闭合,等于0的时候就是断开;

3、推测信号:一些信号的数据从综合采集系统里面是无法得到的,必须通过公式计算出来。计算出来数值之后,加上一个单位显示出来。

我们可以把信号的定义存储在数据库里面,数据如下:

TYPE字段表示这个信号的类型:A是模拟信号,S是状态信号,P是推测信号。根据这个字段建立对应的信号实例,不同类型信号的数据处理就由对应的子类去负责。模拟信号会把采集到的数据加上单位(UNIT)显示出来;状态信号会把采集到的数据根据状态描述(STATE_DESCRIPTION)的定义显示出来;推测信号会按照推测公式(PRESUME_FORMULE)的定义去计算信号的值,然后加上单位(UNIT)显示出来。

我们可以在设备中处理Signal子类的创建,这样也不是不可以。但是,如果我们采用一个工厂,由他来负责Signal对象的建立,这样就完全隔离了设备和信号的每个子类的关系。设备在调用信号对象的时候,完全不需要知道这个实例是属于哪个类型。工厂的代码如下:

 

class SignalFactory
{
    
public static Signal CreateSignal(string dev, string sig)
    {
        
//获取信号的定义
        string sql = 
            
"SELECT * FROM SIG WHERE DEV='" + dev + "' AND SIG='" + sig + "'";
        
//查数据库表
        
        
//判断需要创建的类型
        Signal signal = null;
        
if (type == 'A'
        {
            signal 
= new AnalogSignal();
        }
        
else if (type == 'S'
        {
            signal 
= new StateSignal();
        }
        
else if (type == 'P')
        {
            signal 
= new PresumeSignal();
        }
        
else 
        {
            
return null;
        }
        
        
//设置Signal的配置参数
        signal.SetUnit(unit);
        signal.SetStateDescription(state_description);
        signal.SetPresumeFormule(presume_formule)
        
        
return signal;
    }
}

如果我们需要显示设备上的某个信号,这样就可以了:

 

Signal sig = SignalFactory.CreateSignal(dev, sig);
string s = sig.GetDisplayString();

其实,我们还可以采用一些小手段,比如利用反射的方式,彻底的把Signal的各个子类与其他的代码隔离开,甚至连SignalFactory都不需要和子类产生联系。我们可以把信号配置的数据修改一下:

TYPE字段原先设计的是一个标志(A、S和P),现在直接记录类型的命名空间和名称。SignalFactory在创建实例的时候,直接查出TYPE字段的内容,然后按照这个类的名称,就可以用反射的方式创建需要的实例。这样,无论是Signal的创建者,还是调用者,都不需要知道他们创建和调用的实际类型是哪一个,各种信号的数据和显示处理完全是由Signal的每个子类负责,程序就很好的符合了开放闭合原则。假如以后出现了一些很独特的信号采集和计算方式,甚至不得不采用硬编码的方式去实现,也不会对其他代码造成不良影响影响,维护起来非常的方便。

我们利用一个工厂解决了信号数据采集的问题,并且为下一步可能发生的变化留下了扩展的可能。下面看看告警应该怎样处理。我们先简单的考虑一下告警的形成:首先是在设备上采集到最新的实时数据,然后按照某个规则去判断这些数据是不是符合了告警的条件。在符合条件的情况下,在设备上面产生告警。在大部分情况下,一个告警只和一个设备有关,但是也有这样的情况:某个告警条件需要同时判断多个设备上的多个信号。于是我们设计出下面这样的结构:

告警的定义保存在告警定义数据表里面,如下:

表里面的CONDITIONA字段表示告警条件,这是一个公式,判断的时候把信号的数值代入,然后判断公式条件是否得到满足。如果满足条件,就产生一个告警。

程序的运行时序是这样:设备对象得到自己所包含的信号上的实时数据,然后找到与自己相关的每一个告警对象,依次调用他们的Judge方法。Judge方法根据告警条件公式判断是否有告警存在,如果存在的话,就把相关设备的HasAlarm属性设置为True。就这样,程序的主要功能实现了。

下面是这个程序的一个客户端界面:

界面的左侧是一个树,表示设备的分类关系,每个叶子表示一个设备;当鼠标在树上点击一个设备,右侧的列表视图上显示这个设备上的信号和采集数据;如果设备上有告警,对应的树节点要标示一个显著的颜色,并且状态栏上要显示最近的告警。

要实现界面的刷新,最简单的方式莫过于在窗体上设置一个定时器,每隔一段时间检查一下所有设备的HasAlarm属性,发现有告警的设备,就把这个设备在树上的图标换掉,然后再把告警的内容显示在状态栏上。但是这样做有一个缺点,定时器的时间间隔无论怎样设置都是不合适的,时间太长了,可能会有一些告警要很久才能显示出来;时间太短的话,可能很多次刷新都没有告警,白白的消耗资源。这种刷新的机制是不合理的。要解决这个问题,可以采用观察模式(Observer)。一个对象需要等待另一个对象发出一个消息,然后再采取响应措施,等待消息的对象不需要知道消息如何发生、何时发生,发出消息的对象也不需要知道谁会关注这个消息、如何响应。这种情况就可以采用观察模式。

使用C#实现观察模式有一种非常简单的方法,那就是事件。我们可以在设备上定义一个事件:告警。当设备的HasAlarm属性被设置的时候,他会检查参数,如果发现参数为True,就发出告警事件。设备的代码片段如下:

 

class Device
{
    
public event System.EventHandler Alarm;//定义告警事件
    
    
public Device()
    {
        
this.Alarm += new System.EventHandler(this.Device_Alarm);
    }
    
    
public void SetHasAlarm(bool has)
    {
        
if (has == true)
        {
            Alarm(
thisnull);//发出告警事件
        }
    }
    
    
private void Device_Alarm(object sender, EventArgs e)
    {
    }
}

当设备上产生告警的时候,设备对象会发出Alarm事件。界面上的树视图可以捕获这个事件,将对应的树节点图标设为红色;状态栏也可以捕获这个事件,把设备上的告警显示出来。比起定时轮循,这是一种更加合理高效的方式。

对象设计是不是合理,所参照的标准是这个设计是不是反映了业务需求的实际概念。要做到真实的反映业务需求,最根本的方法是要深刻的去理解需求,深入的探索业务人员的工作和思想,甚至去留意他们自己都无法用语言表达的思维环节。在一个涉及者众多的企业支撑系统中,这种情况很常见的。有经验的业务人员肯定会积累很多这样的思想,体现了这些思想的对象模型才是最优秀的。要让软件系统来帮助业务人员进行工作,也就必然无法回避这样的问题。合理的使用设计模式可以最大限度的降低系统的复杂程度,但是归根到底,复杂程度是由业务需求所决定的。当对象设计基本清晰之后,设计模式可以帮助设计人员更好的处理对象之间的复杂关系,建立一个更加简单、稳定的对象模型。同时,设计人员也可以从设计模式中得到启发,去发现一些原本没有留意的细节。

posted on 2007-02-15 17:15  小陆  阅读(13210)  评论(13编辑  收藏  举报