3 类
在OOP的开发过程中,类是系统的基础和关键部件,类设计的水平决定了整个系统设计水平,因此我们必须不断提高类的设计能力,而且它遵守最简单的往往最重要的原则,一个系统中的实体对象及用于传输的数据对象(它们往往也是服务的输入、输出对象)的设计更加重要,因此我们必须把数据对象的设计提到一个相当的高度,数据类反映系统的本质,它们是系统中相对稳定的部分,有了良好的稳定的数据类设计,才能得到一个良好设计的系统,因此必须在数据类设计上下大力气,数据类设计水平反映你对业务领域的认识深度,影响后续的所有设计环节,换句话说没有良好的数据类设计,就不可能得到一个好的系统。
3.1 软件系统设计的基本原则
为了更好地进行类设计,首先介绍软件系统设计的几个重要原则:
1)面向本质,不要面向表象。
在一个系统中数据、数据结构、实体对象和与行为相关的传输对象是业务领域的本质,功能实际上是表象,众多因素会导致功能需求的差异,而大多数软件设计人员以功能为导向设计系统,实际上是本末倒置,也是造成目前软件系统难于发展和维护的重要原因;但一个业务领域中的关键业务处理逻辑是相对稳定的,是本质的,是设计要重点考虑的另一部分;设计人员经常将功能与核心业务逻辑混为一谈,实际上功能是通过调用一个或几个核心处理逻辑完成的,功能是千变万化的,核心业务逻辑是稳定的,他反应行业本质。这导出另外一个重要的设计原则:
2)分离基础业务处层与功能处理层
基础处理模块反映行业的核心处理逻辑,是本质和稳定的,功能处理模块是面向服务的,是易变的,基础处理模块是功能模块的基础支撑,功能处理模块反映粗业务逻辑,基础处理模块反映稳定的细业务逻辑,坚实稳定的基础处理层是整个系统的基石,两层的合理划分,是系统稳定和灵活的基础。
3)分离数据与逻辑
在一个系统中,数据与逻辑比较而言,数据是易变的(这里的数据不是前面提到的数据类-数据结构,而是参数),逻辑是相对稳定的,如果两者混在一起,整个系统就无法安定了和适应变化了,例如打印的位置、显示的属性,业务控制参数(费率、利率、业务方式、客户性质等),如果这些数据些死在程序中,将使系统僵死而失去活性,如何全面完整地将数据从逻辑中剥离出来,剥离出来的数据如何存储与管理,是设计中的关键话题;我们的设计开发平台,在ADM(Applaction Description Model)中已经为确定类型的参数和不确定类型的参数建立的存储模型,不确定类型的参数可以使用CO-通用配置参数模型,极特殊的可以继承Root类自行定义X类参数以满足具体要求,这样的数据可以通过参数工厂进行统一的存储管理,可以通过通用维护界面(或专用维护界面-对于X类参数)进行可视化维护。也就是说平台解决了存储和管理的问题,但如何正确地分离则是你设计师要认真思考反复推敲的了。
4)开闭原则
软件实体(模块,类,方法等)应该对扩展开放,对修改关闭。这即是一个原则也是系统设计的重要目标,就是让软件系统即稳定又开放(注意这是一对矛盾),这可以称为软件系统设计的总则,前面谈的原则也是为它服务的,该原则后面还会介绍,它比较抽象,需要你不断去体会和实践,在你未深入理解时,你努力遵守上面的几个原则,另外在设计过程中努力认识和识别变与不变的东西,并将之科学地分类开,类似信息隐藏技术,实际上分离变与不变、分离数据与逻辑都是贯彻开闭原则的重要方法,为了是你更好地理解上面的概念,下面给出一些具体指导:
软件系统中结构化的(如实体类、传输类)、反映行业的基础业务逻辑(如银行的记账逻辑、计息逻辑)是稳定的,功能和表示层(如界面、报表等)、技术手段(如通讯协议、加密方法等)是易变的。分解出不变你就获得系统稳定的基础,管理易变你就获得系统灵活性。
在我们的平台体系下已经对界面、报表、通讯、加密等进行和很好的剥离和封装,在具体系统设计中需要重点解决的就是实体及传输类设计,基础服务层与功能层的分离,业务参数与业务逻辑的分离。
实体类相对比较容易设计,实际上它与数据库设计紧密相关,在我们的平台体系下他们实质就是一体的,与行为相关的传输对象,设计上要多下功夫,首先你必须对整个业务领域的所有功能进行归类分析,并以此为基础进行传输类的类图设计,以银行为例,首先传输对象必须有一个共同的基类(它包含各种传输类的交集属性),然后在功能归类分析的基础上,对各功能行为属性进行分析和抽象,发现上千种功能,从行为属性上可以划分为如下五大类:
A)客户资金类业务
B)客户一般性业务
C)内部资金类业务
D)内部管理类业务
E)查询类业务
各大类下派生其他子类,如A)可以派生客户现金类、客户转账类、客户外汇类等业务;
但基于行为属性抽象(而不是基于功能)设计的传输类的类树规模将明显缩小,而且它是面向业务本质的,是相对稳定的。细心的你可能会提出一个问题,我们在设计传输类时,首先要对功能进行全面分析,这不是面向功能了吗?不对!这只是一个手段,我们最终的目的是实现对行为属性的抽象,实际上我们无论做什么都必须(也只能)透过现象看本质,功能是表象,我们必须通过它(分析它)才能得到行为属性类图(本质),而且你一定要注意,这属性类图并不是摆在那里,而是需要你的分析、抽象、归纳、推敲,解开重重迷雾,才能得到,这才能体现你的设计能力,也是设计的魅力。强调不要面向功能,不是让你不分析功能,恰恰相反,你需要认真地、反复地分析研究它,直到你真正地理解和消化吸收,你才能开始设计,才能做好设计,强调不要面向功能是指导你不要只看表象,不要照葫芦画瓢,就事论事,面向功能设计的系统是脆弱的、拙劣的、无法适应变化的。
.....待续