当面向对象技术正在将Model对象持久化行为绑定到Model数据自身时，工业界力推的SOA则倡导的是将数据从行为中解耦出来。SOA相关讨论见这里。看似矛盾，实际它们有一个共同点，追求同一个终极目标：松耦合（loose coupling）。
当我们在Java波涛汹涌的潮流中奋击时，我们常常会思考？我为什么要这样做？甚至，我们会想松耦合真的那么酷？可维护性真的是软件唯一？也许我们迷失了方向。
我们要好好探究一下，软件的最大追求是什么？
我们的大学计算机教育只是教会我们如何编程？这如同技工学校中教会学员如何使用车床一样，当我们学会了编程，接下来是什么呢？是不是就没有了呢？是不是就是如同车工那样只需日复一日的反复编程呢？
其实，当你在一个系统中持续编程（增加新的东西），这个系统就变得复杂了，你面临最大的挑战是如何整理你自己的产物。
也就是说：大学教育只教会我们如何“增加新的东西”，但是没有教育我们如何“整理这些东西”，而后者是目前软件领域日新月异不断发生的革命的新动力。
下面我们以具体代码来说明“增加新的东西”和“整理这些东西”完全属于不同层次的学问，有些人谈到软件只会想到算法和数据结构，认为这些才是科学，其实这是将软件数学化，软件不只是科学计算的工具，它自身也是一门科学，更象管理学/经济学一样，是科学和艺术的结合。
在最近Java(TM) Boutique网站上刊登出一篇文章Measuring the Complexity of OO Systems，衡量OO系统的复杂性，该文对软件复杂性几个著名公理进行了详细阐述，这些公理如果你不进行学习和培训，即使你使用OO语言Java等这样工具，还是显示你是“业余”的。
软件复杂性包括以下部分（引自Measuring the Complexity of OO Systems）：
- Cyclomatic Complexity （圈复杂性）
- Response for Class （类的响应）
- Weighted methods per class （每个类重量方法）
Cyclomatic Complexity
Cyclomatic Complexity可以用下面代码来说明：
|
|
其中number of decision points是指一个if else之类的条件判断语句，比如，是下面这个条语句：
| public void isValidSearchCriteria(SearchCriteria s){ if(s!=null) { return true; }else{ return false; } } |
Cyclomatic complexity 对代码的可测试性和可维护性上有很大影响，正如上例指出，当你要测试isValidSearchCriteria()方法 ，你必须写三个测试用例来验证它。
如果这个CC值增加，将有更多的判断点（decision points）数量，也就意味着需要花费更多的力量来测试这些方法。详细更多说明可参考Measuring the Complexity of OO Systems一文。
所以，if else 或while 等条件语句是对真正OO的一种伤害（这是非OO公理见Thomas McCabe），可以极端地说：一个好的OO系统几乎在业务逻辑层看不到超出两个以上条件的if else等判断语句，这些条件语句都是可以被GoF设计模式的状态模式/策略模式等替代（你还在用if else吗）。
当你的Java系统中充满了大量的if else语句，虽然你使用很酷的语言工具，但是说明你的思维是传统过程的，需要重新学习和培训。
Response for Class(RFC)
这是著名的 Chidamber and Kemerer公理之一。以下面代码来说明：
| public class RegistrationManager {
public void createRegistration(RegistrationData regData){ DataAccessManager manager = new DataAccessManager(); } public Registration findRegistration(String regNumber){ //find the registration 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个数.
这个公式可以帮助你让类保持干净，并且和相关行为意义上更加靠近（cohesive）。
以前面的RFC例子说明：如果你将DataAccessManager和AuditManager类中的方法都定义到当前RegistrationManager类中，你会得到一个WMC高值，这说明这个类需要重整了。
松耦合设计
前面章节我们反复提到重整(refactoring)，它的意思就是：你不但会“增加新的东西”，而且还要学会“整理这些东西”（重整）。
正如儿童玩玩具一样，他可以无师自通很快学会玩一个新东西，但是，当他玩完很多新玩具以后，他就很难学会整理他到处乱丢的玩具。由此可见：会编程不值得骄傲（可能源自天生），懂得如何整理才是真正的专业程序员。
现在，让我们回到问题的本质，上述列举了软件的复杂性，复杂会导致难于维护和测试，那我们需要整理，那么整理是否可量化一种程度呢？
我们使用“松耦合”这个概念来表示易于维护、易于测试、易于扩展的程度，当然，松耦合值越高，我们系统更易于维护。当前，软件世界的发展，SOA、Ioc/AOP不都是在追求松耦合的最大化吗？
松耦合一个反义词“紧耦合”，从我们学会玩编程这个玩具开始起，我们就面临两种选择：一种朴素的、无需训练的、近似自然的“紧耦合”路线；一种是经过科学培训的“松耦合”道路。选择哪一条道路就取决于你是否受过专业训练了。
所以，对于编程这个玩具，不在于你是否会玩，而在于你怎么玩？玩的水平。如果不明白这个道理，中国软件的萧条永远不会结束。
