高内聚&低耦合

高内聚、低耦合是软件设计的普遍原则，但在实际的工作中，有时我们并不能清楚的认识到关于它们的两个问题：

1、为什么要高内聚、低耦合。

2、如何做到高内聚、低耦合。

 

高内聚、低耦合这个概念出现的比较早，也是我们在接触软件设计时被告知的第一条原则。但很多人并不清楚，它能给我们带来什么实际的好处，在与有些同事们讨论设计方案的优劣时，有时经常听到这样一句话——这两种功能不是一样的么？让人啼笑皆非，我们此时讨论的并非功能问题，所有的备选方案，只有满足业务功能才有资格成为候选者。功能不是软件设计阶段“设计”出来的，实际上，在这个阶段对功能问题，在主流活动中，除了反馈，我们没有讨价还价的余地很小。在本阶段我们要通过“设计”活动承载的是软件的质量属性，作为一个可能有较长生命周期的软件，可扩展性通常是最重要也最容易被忽视的，原因是可扩展性在软件首次完成时不容易度量，它要靠时间来检验，在结果导向严重的环境中，导致被忽视，但它可以通过“人”来定性的评价（关于能否定量度量，我们在下文中讨论），而众多的软件设计方法都瞄准这一点，其中最具代表性的就是面向对象。

 

高内聚、低耦合到底能给我们带来什么好处呢？它意味着一个模块只做一件事情，关注一个变化，反之，一件事情、一个变化也只应该在一个模块中。这一点是非常重要的，它是提高模块组合能力的基础，软件业之所以稚嫩于其它传统技术行业，正是因为在其它成熟行业中都有着成熟的“方法”和“标准”，而软件介质的特殊性——对设计没有约束，而软件业通常共生于其它行业中，这些都导致“标准”较难形成，没有标准，导致软件开发效率的低下。举几例子：建筑业盖大楼时，设计师不会去考虑钢筋、水泥该如何生产，他需要考虑的是该用哪个规格的（实际上在大部分情况下，这些也不用他们考虑，完全可以参照业界的通过标准）。汽车业造汽车，没有哪家汽车生产公司会亲自生产全部部件。他们都运用了“组合”这一手段，组合意味着低成本、可替换、应变能力强。而在软件内部恰恰缺乏这些，亲自造轮子是常有的事情，出现这类问题的最主要原因是“人的能力和能动”问题，经常出现针对功能做设计、写代码，这样编写出的软件，一旦功能变化，修改范围几乎是不可控的，而一个模块中承载了太多的逻辑也使阅读、理解、维护的复杂度急剧升高。

 

人和计算机理解问题的方式不同，冯.诺依曼计算机理解问题都是扁平和细节的，它能理解的最小和最大单位只有一个——指令，你根本不能对CPU发出“打开资源管理器”这样的高级指令。而人的思维方式是分层的，我们更习惯于高级描述，即使面对日常生活中经常做的事情，例如——吃饭——我们也不习惯于用计算机的方式来思考——夹菜、张嘴、放菜、咀嚼、吞咽，如果要让计算机来完成，实际上还要分的更细。而人一旦面对大量细节，我们出错的可能性就很大。我们的代码不是给计算机写的，而是给人写的，所以应该符合人类的思维习惯——分层。在一个缺乏设计的软件中，恰恰容易出现充斥着大量细节的模块，这些模块只能在当前功能下与周边的特定模块通信，在软件中缺少可以被复用的“零件”，这样的软件可以说不具备组合能力，应对变化的能力的很差（纠正一个概念，衡量应对变化的能力不能只是通过代码量，还要看这个变化会影响到的模块占全部模块的比例）。

 

小结一下，高内聚、低耦合能给我们带来什么？

1、容易理解（再纠正一个观念，有人觉得充斥大量细节的、平铺直叙的代码更容易理解，能直接看到业务是怎么在计算机上执行心里觉得有底，尤其在定位问题时，更习惯这种思维方式。实际情况并非这样，如果你的代码中没有多少的判断和跳转可能是容易读，但如果出现大量的条件和跳转你可能就要崩溃了，不幸的的是，随着维护的增加，判断和跳转将会越来越多——初始化可能是个特例。还有，这样的代码花力气读懂是可能的，在一段时间内也能记住，但如果软件中到处都是这样的代码，你很难掌握全局。最后，说给抱着“定位问题”的思维读代码的同事，发现Bug有两种方式，一种是软件足够清晰，导致Bug很难隐藏，另一种是软件足够复杂，）。

 

能否定量度量？我现在还不知道是否有这样的工具，由于被考察对象多是代码，这增加了度量的难度，尤其是在那些用C语言编写的软件中，不过似乎也不是不可以的，。