编程规则 - 3 类设计规则（1）

 摘要：类设计原则 编程规范 设计规则 编程指导      参阅：概述   命名

3 类

    在OOP的开发过程中，类是系统的基础和关键部件，类设计的水平决定了整个系统设计水平，因此我们必须不断提高类的设计能力，而且它遵守最简单的往往最重要的原则，一个系统中的实体对象及用于传输的数据对象（它们往往也是服务的输入、输出对象）的设计更加重要，因此我们必须把数据对象的设计提到一个相当的高度，数据类反映系统的本质，它们是系统中相对稳定的部分，有了良好的稳定的数据类设计，才能得到一个良好设计的系统，因此必须在数据类设计上下大力气，数据类设计水平反映你对业务领域的认识深度，影响后续的所有设计环节，换句话说没有良好的数据类设计，就不可能得到一个好的系统。

3.1 软件系统设计的基本原则

为了更好地进行类设计，首先介绍软件系统设计的几个重要原则：

1）面向本质，不要面向表象。

在一个系统中数据、数据结构、实体对象和与行为相关的传输对象是业务领域的本质，功能实际上是表象，众多因素会导致功能需求的差异，而大多数软件设计人员以功能为导向设计系统，实际上是本末倒置，也是造成目前软件系统难于发展和维护的重要原因；但一个业务领域中的关键业务处理逻辑是相对稳定的，是本质的，是设计要重点考虑的另一部分；设计人员经常将功能与核心业务逻辑混为一谈，实际上功能是通过调用一个或几个核心处理逻辑完成的，功能是千变万化的，核心业务逻辑是稳定的，他反应行业本质。这导出另外一个重要的设计原则：

2）分离基础业务处层与功能处理层

基础处理模块反映行业的核心处理逻辑，是本质和稳定的，功能处理模块是面向服务的，是易变的，基础处理模块是功能模块的基础支撑，功能处理模块反映粗业务逻辑，基础处理模块反映稳定的细业务逻辑，坚实稳定的基础处理层是整个系统的基石，两层的合理划分，是系统稳定和灵活的基础。

3）分离数据与逻辑

在一个系统中，数据与逻辑比较而言，数据是易变的（这里的数据不是前面提到的数据类-数据结构，而是参数），逻辑是相对稳定的，如果两者混在一起，整个系统就无法安定了和适应变化了，例如打印的位置、显示的属性，业务控制参数（费率、利率、业务方式、客户性质等），如果这些数据些死在程序中，将使系统僵死而失去活性，如何全面完整地将数据从逻辑中剥离出来，剥离出来的数据如何存储与管理，是设计中的关键话题；我们的设计开发平台，在ADM（Applaction Description Model）中已经为确定类型的参数和不确定类型的参数建立的存储模型，不确定类型的参数可以使用CO-通用配置参数模型，极特殊的可以继承Root类自行定义X类参数以满足具体要求，这样的数据可以通过参数工厂进行统一的存储管理，可以通过通用维护界面（或专用维护界面-对于X类参数）进行可视化维护。也就是说平台解决了存储和管理的问题，但如何正确地分离则是你设计师要认真思考反复推敲的了。

4）开闭原则

软件实体（模块，类，方法等）应该对扩展开放，对修改关闭。这即是一个原则也是系统设计的重要目标，就是让软件系统即稳定又开放（注意这是一对矛盾），这可以称为软件系统设计的总则，前面谈的原则也是为它服务的，该原则后面还会介绍，它比较抽象，需要你不断去体会和实践，在你未深入理解时，你努力遵守上面的几个原则，另外在设计过程中努力认识和识别变与不变的东西，并将之科学地分类开，类似信息隐藏技术，实际上分离变与不变、分离数据与逻辑都是贯彻开闭原则的重要方法，为了是你更好地理解上面的概念，下面给出一些具体指导：

软件系统中结构化的（如实体类、传输类）、反映行业的基础业务逻辑（如银行的记账逻辑、计息逻辑）是稳定的，功能和表示层（如界面、报表等）、技术手段（如通讯协议、加密方法等）是易变的。分解出不变你就获得系统稳定的基础，管理易变你就获得系统灵活性。

在我们的平台体系下已经对界面、报表、通讯、加密等进行和很好的剥离和封装，在具体系统设计中需要重点解决的就是实体及传输类设计，基础服务层与功能层的分离，业务参数与业务逻辑的分离。

实体类相对比较容易设计，实际上它与数据库设计紧密相关，在我们的平台体系下他们实质就是一体的，与行为相关的传输对象，设计上要多下功夫，首先你必须对整个业务领域的所有功能进行归类分析，并以此为基础进行传输类的类图设计，以银行为例，首先传输对象必须有一个共同的基类（它包含各种传输类的交集属性），然后在功能归类分析的基础上，对各功能行为属性进行分析和抽象，发现上千种功能，从行为属性上可以划分为如下五大类：

A）客户资金类业务

B）客户一般性业务

C）内部资金类业务

D）内部管理类业务

E）查询类业务

各大类下派生其他子类，如A）可以派生客户现金类、客户转账类、客户外汇类等业务；

但基于行为属性抽象（而不是基于功能）设计的传输类的类树规模将明显缩小，而且它是面向业务本质的，是相对稳定的。细心的你可能会提出一个问题，我们在设计传输类时，首先要对功能进行全面分析，这不是面向功能了吗？不对！这只是一个手段，我们最终的目的是实现对行为属性的抽象，实际上我们无论做什么都必须（也只能）透过现象看本质，功能是表象，我们必须通过它（分析它）才能得到行为属性类图（本质），而且你一定要注意，这属性类图并不是摆在那里，而是需要你的分析、抽象、归纳、推敲，解开重重迷雾，才能得到，这才能体现你的设计能力，也是设计的魅力。强调不要面向功能，不是让你不分析功能，恰恰相反，你需要认真地、反复地分析研究它，直到你真正地理解和消化吸收，你才能开始设计，才能做好设计，强调不要面向功能是指导你不要只看表象，不要照葫芦画瓢，就事论事，面向功能设计的系统是脆弱的、拙劣的、无法适应变化的。

  .....待续