当你的Java系统中充满了大量的if else语句,虽然你使用很酷的语言工具,但是说明你的思维是传统过程的,需要重新学习和培训。
Response for Class(RFC)
这是著名的 Chidamber and Kemerer公理之一。以下面代码来说明:
public class RegistrationManager {
public void createRegistration(RegistrationData regData){
DataAccessManager manager = new DataAccessManager();
AuditManager auditManager = new AuditManager();
//save the registration
manager.saveRegistration(regData);
//audit the creattion
auditManager.createAuditRecord(regData);
}
public Registration findRegistration(String regNumber){
DataAccessManager manager = new DataAccessManager();
Registration reg = null;
//find the registration
reg = manager.findRegsitration(regNumber);
return reg;
}
}
这个类RegistrationManager 依赖其他两个类DataAccessManager 和 AuditManager 。
按照公理公式:
RFC = M+ R (M = 这个类中方法个数. R = 其他总数)
在上例中,我们统计类响应RFC数目如下:
在RegistrationManager中方法数目 = 2
调用了DataAccessManager的方法数目 = 2
调用了AuditManager的方法数目 = 1
这样:RFC(RegistrationManager) = 2 + 2 +1 = 5
当一个类和很多其他类存在依赖时,它就变得复杂甚至难以修改和维护,这样,RFC值越大,表示你的系统味道越坏。
当然,因为OO系统是基于类和方法,不可能开发出一个0值RFC的系统,但是我们追求的目标是一种平衡,当你设计OO系统时,必须时刻注意这些公理,尽量避免类的编码达到一个RFC高值。
我们如果使用现代一些模式:如Ioc模式,可以帮助我们方便不费力气地达到这样一个平衡,因此,使用Spring/Jdon之类框架是降低RFC值的一个捷径。
Weighted methods per class
之前几个公理是介绍如何通过类之间交互调用使得软件系统变得异常复杂,一个系统或一个特定的类自身也会变得异常复杂,有很多方法,Weighted Method Per Class公理帮助我们量化定义这些情况。
这个公理定义会依据两种情况:一个类实现;不同的实现。
WMC 1 = 一个类中所有方法个数.
WMC 2 = 所有方法的Cyclomatic Complexities个数.
无论你选择哪一种公式,一个WMC高值显示这个类也许需要被重整成多个类。
这个公式可以帮助你让类保持干净,并且和相关行为意义上更加靠近(cohesive)。
以前面的RFC例子说明:如果你将DataAccessManager和AuditManager类中的方法都定义到当前RegistrationManager类中,你会得到一个WMC高值,这说明这个类需要重整了。
松耦合设计
前面章节我们反复提到重整(refactoring),它的意思就是:你不但会“增加新的东西”,而且还要学会“整理这些东西”(重整)。
正如儿童玩玩具一样,他可以无师自通很快学会玩一个新东西,但是,当他玩完很多新玩具以后,他就很难学会整理他到处乱丢的玩具。由此可见:会编程不值得骄傲(可能源自天生),懂得如何整理才是真正的专业程序员。
现在,让我们回到问题的本质,上述列举了软件的复杂性,复杂会导致难于维护和测试,那我们需要整理,那么整理是否可量化一种程度呢?
我们使用“松耦合”这个概念来表示易于维护、易于测试、易于扩展的程度,当然,松耦合值越高,我们系统更易于维护。当前,软件世界的发展,SOA、Ioc/AOP不都是在追求松耦合的最大化吗?
松耦合一个反义词“紧耦合”,从我们学会玩编程这个玩具开始起,我们就面临两种选择:一种朴素的、无需训练的、近似自然的“紧耦合”路线;一种是经过科学培训的“松耦合”道路。选择哪一条道路就取决于你是否受过专业训练了。
所以,对于编程这个玩具,不在于你是否会玩,而在于你怎么玩?玩的水平。如果不明白这个道理,中国软件的萧条永远不会结束。
责任编辑:cyth