Cohesion&Coupling

http://www.infoq.com/news/2008/04/soa-cohesion

高内聚，低耦合不是什么新鲜东西（曾经某人的签名档）。如果吧低耦合和WebService或者SOA关联起来。那么这篇文章就是高内聚和低耦合的一场争论。

JIm Webber首先说高内聚高耦合是不好的，但低内聚低耦合的系统也同样不好扩展。进而他提出WebService不能太松散，必须要反映一个真实的商业需求才有存在的意义。换句话说更细的划分是没有意义的。（这倒是某人说过的，不能把所有的方法都封装成WebService，要在现实世界中存在的东西才有WebService)

而JJ提出内聚是过去的标准，现在要用全新的眼光来看SOA，就要提倡低耦合。

讨论还在继续。而他们显然都认为内聚和耦合不能并存或者说不能同时发展。似乎这两者必然是此消彼长的。为什么呢？如果确定一个明确的边界，就不能同时着力于两者吗？

也许是不能的。因为边界不明确。即使是文章开始部分Steve提出的三种“好”的内聚，在现实世界中也不是永恒稳定的，变成“坏”的内聚的情况随时可能发生。那么软件重构就不可避免。如何能快速地适应呢？如果一开始就把最有可能变成“坏”的内聚的“好”内聚们低耦合化，或者说WebService化，也就是分开来。是不是会好一点呢？

http://udidahan.weblogs.us/2008/04/23/visual-cobol-enterprise-processes-and-soa/

但还是那句话，边界不是确定的。某人的文章又搞出个Enterprise Process和Business Process的区别。这足以说明，很多东西完全在乎你怎么看。你可能在做低耦合的时候，破坏了一个东西的内聚性；又或者在内聚一些东西的时候，忽视了它们间低耦合的可能性。两者的结果都是代码很难改： 前者的产物是一堆分散的代码，改一个简单的过程要同时变很多地方，虽然有重构工具的帮忙，也很难说不改错一两个。后者的产物是一份自成一体的超级代码，也许没几个人能看懂，更不用说改了，而且多人团队的话还存在一个版本同步的问题。

 

这两种情况可以说都是常见的头疼的状况。有没有银弹呢？我想，只有在开发者事先已经对这种边界有一定的正确预期的情况下，事先的一些假设不能被打破。那么内聚是好的,否则。。。。至于耦合那种不良后果，虽然可以说是没有内聚好的结果。但世事逻辑相类者众，只要有了耦合和重用，那么很可能就有从新组合优化的空间的存在。。。。说来说去，还是没有一个简单的答案。。。。。