从分层模型谈三种耦合

1      分层架构的缘由

通常我们在做J2EE项目的技术架构时，通常会考虑一种分层的模型，目前非常流行的分层做法是控制层一般采用struts,springmvc，在业务层采用spring，EJB，在持久层采用hibernate,ibatis，jdbcTemplate等。那么为什么要采用这种模型呢？这是我们需要考虑的问题。

其实采用分层模型主要目的是为了解耦，为什么需要解耦？因为我们的项目是做应用解决方案的，它是一种定制化系统，而定制化系统的一个比较明显的特征是需求的随时变更，而为了去适应这种变更我们不得不从两方面去解决这个问题，一方面是售前侧，即让售前与客户沟通，尽量回避需求的变更（相信做过售前的人会明白要想让客户明确自己想要什么是有多么地困难），而另一方面则是通过技术手段进行解决，即构建一个灵活的，充分解耦的技术框架，以期能够快速地对需求变更做出响应。自然，从技术层面来说，构建一个分层模型的架构就是为了去适应需求的不断变更，尽最大可能地进行解耦。为什么分层模型能够做到解耦呢？

因为对一个系统进行分层处理，就是为了将一个系统按其功能的最终呈现而进行职责的分离，不同的层次进行不同职责的功能划分，比如展现层用来对数据进行展现的，控制层主要用于进行业务请求控制的，业务处理层主要用于进行业务逻辑处理的，持久层主要用于进行数据持久化和读取的。为什么这么分呢？因为人们发现按这种方式对整个业务进行分离之后，带来了很大的好处，比如某一处的修改，只会对本层有一定的影响，而不会影响其他层，这样就做到了修改最少，风险最小。在一个非常复杂的系统中，甚至于根据业务逻辑会构建更加多的层。

应用分层模型来解决实际的应用系统在我们所见的很多系统中都有所体现，比如我们所使用的计算机，就分为硬件层，硬件驱动层，操作系统层，应用软件层，又比如OSI网络协议的分层更是体现了分层所带来的好处。所以我们在日常的系统构架中，采用分层来进行技术的解耦是很值得借鉴的。

2      一种滥用现象

但是，另一方面，我们需要注意一种滥用现象，即表明上看起来是采用了分层的，但实际上却不是，而这种滥用的现象表现在两个方面：

一是只是简单地对各技术进行集成，而并不明白所采用的技术为何适用于此，即太过于依赖于技术本身，反而造成了对技术的耦合，这种情况下的典型表现是，对所采用的技术进行了相应地集成，同时进行了深度地封装，从而导致了各层之间职责不分明，各层之间依赖过大。

二是跨层调用，即会出现一些通过一些基类的封装继承，而回避了各层之间的功能职责，处理流程，甚至于会出现控制层能够直接通过某种手段将持久层的数据用于进行展现层的呈现。

这种滥用现象的后果比较严重，太过于依赖于技术本身，尤其是开源技术本身，所带来的是新员工入职时的工作上手理解熟悉过程较为复杂，另一方面则是人员的流失可能会造成一定程度的损失。并且在企业的进一步扩大发展中，固定的技术封装也会对业务的扩展造成一定的阻碍。

3      程序员的心理

大凡愿意做程序员的人，一般其心理比较高傲一些，因为他们觉得这是一个富有挑战性的行业，很多时候，当一个程序员在很好的解决某一个问题时，会有很强的成就感，他们会因为这些兴奋，而如果遇到解决不了的问题时，他们会想方设法也要进行解决，哪怕是不在工作时间，他们仍然会考虑问题的解决方法，因为这是由他们的性格特点决定了的。但是有一种问题程序员却不想遇见，就是知其然而不知其所以然的问题，那么这是一种什么问题呢？

我们假定这样一种工作情况，一个程序员需要开发某个功能，这个程序员自然希望对这个功能的前因后果进行有效控制，做到心里有数。但是此时有一种情况出现了，有人告诉他，应该怎么配置，怎么命名，怎么继承，怎么调用，然后你的功能就算做完了。至于为什么就算做完了呢？程序员也不清楚，他只知道就这么用，如果他想更进一步地去了解，对不起，还真的有些难，因为面对一个庞大的，深度封装的框架，即使全部是开源的方式展现在你面前，他也无从下手，因为那些代码不是他写的，并且通常一个基类有太多的方法了，甚至是一个巨类，而基类彼此之间的调用又太复杂，关系太乱。面对这么一个沉重的框架，此时的程序员就会在心理产生一种严重的挫败感沮丧感，他觉得即使我完成了某个功能，但我不知道为什么就完成了，这就是知其然而不知其所以然的情况。这种情况带来的后果是很严重的，一方面会让程序员觉得没有什么成就，自己的技能也没有进步，所带来的后果是人员的信心丧失和流失，另一方面如果一旦出现某个特殊地需求，仅仅这么配置继承一下，是不能解决这种特殊需求的问题时，程序员就需要其他相关人员的配合，这不是另外一种耦合么，即人员关系的耦合。

所以当我们在框架系统的技术框架时，所需要考虑的就是要回避三种情况的耦合，即功能耦合（此种情况指的是类级别的耦合），技术耦合（此种情况指的是对技术过度依赖，过度封装）以及人员耦合（此种情况指的是面对同一问题，需要多人进行修改,或者多人依赖于某个人提供的基类进行实现）。