编程规则 - 3 类设计规则 (2) 类设计的基本要求

 

 

3.3 类设计的基本要求

    上面讲述了系统设计和类设计的基本规则,理论性较强,你也许一段时间难以理解好,下面介绍类设计的基本要求,更加易于实践,你需要认真做好,上面的那些规则你可以在实践过程中逐步理解,软件设计是一门实践科学,纸上谈兵永远难以得其门而入,实践是最好的老师,不过你还是要努力体会上面原则和方法,它会让你少走弯路。简单地说设计类时的基本要求是:

1) 类要短小、职责单一(SRP单一职责原则)

2) 类要高内聚低耦合

3) 类及类之间的关系要有合理的结构化体系。

这几条看似很简单,但由于概念抽象,还是不易于理解和把握,下面会分别说明,在说明之前,先给出较通俗的类设计基本要求:

a) 类要描述客观业务领域和解决方案(技术领域)的真实对象;

b) 类要有总体架构体系;

c) 类要有一个简洁的名称;

d) 类要尽可能隐藏内部信息;

说明:a)告诉我们不要按照我们的臆想设计类,不要创造怪物(软件工程中传说的人狼就是这样制造出来的啊),面向对象不仅仅是OO技术,更重要的是你在设计时要面向客观的业务领域对象,每个类都必须与实际业务领域和技术领域的客观事物对应,如果找不到对应的事物,你就要注意了,你可能在创造怪物。你可能会说我需要这个类,但是的确找不到对应的事物;这时你需要换个思路,事实上你需要把业务领域想象为一个全手工作业的系统,这时需要的事物在这个领域中就都出现了,其实就是将业务活动打回到原始手工状态(没有计算系统,纯手工系统如何运作的状态),例如纯手工作业的银行系统,银行前台会有接柜的柜员,后台会有会计、记账员,他们要使用各种凭证、账本、台账和登记簿,这些凭证、账簿等就是我们提炼实体对象的客观事物,各种“员”,就是我们提炼操作、服务类对象对应的客观事物;如果这种手工银行准备实现通存通兑,就需要有一个集中的后台部门,前端柜员需要通过电话或传真,把客户要办的业务信息发到后台,后台根据集中的账簿进行处理(实际上早期的银行的确如此处理业务),这时就引出了通讯、报文等事物,也就更接近目前C/S(或B/S)模式的业务系统了,解决方案领域的事物就出来了。这时你可能就找到了面向对象真正含义,并为你的类找的了对应的可观事物,如果你还没找到,你就要检讨了,极有可能你在制造怪物。

    模拟手工往往是对软件系统设计的贬义说法,但是两个方面:其一,客观业务领域是通过几十年业务发展形成的,积累了人类的智慧,理应作为我们系统设计的重要参考。其二,我们在设计时也不能盲目机械地模仿,而必须进行分析、抽象,综合、提炼去伪存真,你就会发现—对象就在现实中,真理可观存在,等待你智慧的大脑去发现

   b)在做类设计时,除了做好一个具体类的设计,还必须做好与类相关的架构设计:

包结构设计,包是类的容器,一个系统通常会有若干类构成,这些类如何合理地组织起来,有一个清晰的组织结构是非常重要的,必须重视包结构的设计。

类的继承结构设计,类实际上是生存在一个环境之中,仅注重类自身的设计还远远不够,必须重视类的继承关系及相互关系(下面会介绍),我们许多设计,都把类设计成一个独立体,天下独尊,按着a)中的原则,类是要与客观事物对应的,而客观世界中是没有这种独生独长的事物的,石头里蹦出来的猴子只是神话中的故事,因此,我们的类设计必须杜绝不实现任何接口也不继承任何类的设计,除非你本身就是接口或基类,同时基类和接口必须由总体组设计。

事实上,类主要划分为两大类,数据类(如实体对象、传输对象等,相当于java Bean)和行为类(如前端的AEM、后台的服务),在我们的开发体系下,已经分别确定了他们的顶级接口和基类,我们设计的类必须遵循此继承体系。尽管如此,在此体系之下的具体类继承体系的设计更为重要,涉及到你对一个业务领域的认识水平,例如我们在设计银行核心系统的传输对象时,如何将银行上千个功能对传输对象的要求,分解为几大类,各大类下再如何划分为若干小类,从而用一套结构合理、小规模的类满足银行全部功能对数据传输的细节要求,对于同一种类的业务通过基类的拓展,实现所有相关子类的拓展,底层子类的修改又不影响其他类,达到稳定与拓展的均衡。

类的依赖层次,尽管在系统设计过程中,我们不断强调解耦!解耦,但如果一个类与任何其他类都无关联,那么该类也就没用了,也就是说类必然会与其他类相互作用和依赖,必然要耦合,问题的关键在于如果将耦合降到最低,做到必须耦合的才耦合,依据最小知识原则和依赖倒置原则,一个类尽可能依赖最少的类,在与非本包内的类耦合时,要依赖接口、基类或抽象类,不要依赖非本包的具体类。下图给出了一个类依赖关系示意图:

 编程规则 - 3 类设计规则 (2) 类设计的基本要求_第1张图片

 

      两个包之间通过接口依赖,更进一步可以通过放在公共包中的工厂方法获取B包中的实际对象,同一个包内的类之间的依赖关系要有合理的层次,合理的依赖层次能够降低类的耦合度,要做到这样,类设计要遵循单一职责原则和最小知识原则,不与陌生人说话,只和朋友圈打交道。这样就可以将类与类之间的影响降低到最小,从而利于系统的拓展和稳定。

c)类要有一个简洁的名称,类的名称要能够很好地、准确地、简明地描述其职责,这也是坚持一个类是否职责过多的好办法,如果你没办法为类起一个简单、准确的名字,可能意味着:①这个类职责太多;②这个类职责不清;③你还没有为它确定一个好名字;如果是最后一点,你可以先为它起一个朴实的名字,简明地表达它的职责就好,记住当有了更恰当的名字是,要积极地重构,一个恰当准确的名字对于类非常重要,名如其类、类如其名啊。

类名应该是名称或名词短语,不应该是动词。

    d)类要尽可能隐藏内部信息;我们规定类的属性必须私有化,尽可能不对外提供设置方法(数据对象和传输对象除外),类的方法不需要公开的就一定不要公开,内部使用数据模型(如List、Set、Map等)不允许对外暴漏。

       下面再对前面1)-3)原则说明如下:

1) 类要短小、职责单一(SRP单一职责原则)

短小不是目标,职责单一而完备才是关键,事实上,世界上一切事物的进化过程就是一个分工越来越单一明确的过程,以生物进化为例,最原始的生命只是一堆蛋白质簇拥而成,没有分工、组织松散,因此也非常脆弱,后来逐步进化,一部分负责行走,一部分负责进食,一部分负责消化,一部分负责运输,逐步就形成组织和器官,逐步走向生命的高级形态;同样软件系统也是一个无形的生命体,没有严格分工、组织松散混乱的系统必然是一个原始的软件体,有着良好体系结构、分工明确具体的软件系统才是一个处于高级形态的软件体。类作为构成软件体系的基本单元,它必须职能单一而完备,要遵循SRP原则。

2) 类要高内聚低耦合

如果类满足了单一职责原则,它往往就高内聚了,因为它仅围绕单一职责工作,专注自然就内聚,一个类首先它的属性必须相对少,所有的属性都是它必须拥有的,剔除与其职能无关的属性;其考察一个类的内聚度,可以通过考察它的方法与它的属性之间的紧密程度,如果每个方法都使用到多个属性,表示它的内聚度是比较高的,反之内聚度是比较低的,内聚度高表明类的属性和方法相互依赖、相互结合成为一个逻辑整体,专注于一个职责。

低耦合,要参照类的依赖层次的说明处理好类的依赖关系。

3) 类及类之间的关系要有合理的结构化体系。

参见上面关于b)的说明。

你可能感兴趣的:(编程,工作,bean,制造,生物,架构设计)