High cohesion and low coupling
WHAT
"High cohesion" and "low coupling" is a concept of software design and development often appear. They are both good ways to design, but also the quality of the design of the evaluation criteria. "High cohesion," say, a business function, and the code should be placed as far as possible it involves a module; "loosely coupled" is that a service should be minimized dependencies on other services or functions of the module.
"High cohesion and low coupling" also appears in pairs so
In fact, this concept applies not only to the software industry. If you are otaku / house women, high cohesion is to eat and drink Lazard sleep do not go out, low coupling is not dealing with people. If you are office workers, high cohesion is the work by themselves have the final say, less communication and collaboration across groups is low coupling / cross-sectoral. If you often deal with the government, we must remember the past, to prove to the government to do a run eighty-nine departments cover a dozen chapters of trouble, which is actually the government services, "low cohesion" consequences - later to streamline government services process, a window cover complete all chapters, this is the kind of "high cohesion" service. If you are a heavy user of Apple's, be sure to "closed environment" experience profound: it is certainly able to provide a good service, but caught them after --iPhone, iPad, macbook, iCloud, etc. - so, even if an service was untenable, or can not meet the demand, and also can not easily escape out, changed, but so. This is the "high coupling" brings problems.
A "high cohesion and low coupling" Meow ......
WHY & WHY NOT
Advantages and disadvantages of high cohesion and low coupling are obvious.
advantage
If a module, the system can achieve a high cohesion, low coupling, then it has a very high scalability. High scalability means "future possibilities": function does not meet the new requirements, a simple extension inside the module will be able to meet; meet the requirements of the performance, the system will be able to tap the potential internal standards; technology too old to be updated updating, and you will be able to complete the metabolism ......
That might be somewhat difficult to understand, we, for example sub-bar.
对宅男/宅女来说，高内聚就是吃喝拉撒睡都不用出门，低耦合就是不用跟人打交道。这样一来，我想吃披萨就吃披萨，想喝两碗豆浆就喝两碗豆浆，完全不用顾虑别人想吃什么、别人会说什么。这样的生活惬意不？
对上班族来说，高内聚就是工作都由自己说了算，低耦合就是跨组/跨部门的沟通协作少。这样一来，我想用数据集A就用数据集A，想用数据集B就用数据集B；想用Excel用Excel，想写脚本写脚本；想用PPT汇报就用PPT汇报，想用demo汇报就用demo汇报。这样的工作快乐不？
我反正是……
技术上……我还是举个例子吧。我们系统中有一个模块，用于处理用户短信验证操作。签约验证成功后，针对具体的业务还需要做一些后续处理。随着业务的不断发展，后续业务处理从最初的一套逻辑增加到现在的五套逻辑。此外我们还做了一些技术优化，如优化库表结构、增加并发处理等，最后的流程大概是这样的：
短信验证模块的基本流程
由于整个短信验证模块、以及后续业务处理模块都做到了高内聚、低耦合（自吹自擂脸），因此，无论是业务扩展还是技术优化，都只影响到了各自对应的模块，其它模块、功能对此毫无感知。尤其是业务扩展、增加一个后续业务处理模块时，其它后续业务处理模块丝毫不受影响。没有影响意味着开发不用改代码、测试不用回归测试、上线时间可以缩短、老代码里不会引入新问题……
可见，高内聚低耦合的设计能带来多赢的结果。对开发来说，改动的代码当然是越少越好——高内聚低耦合的设计能减少要修改的代码量。对测试来说，测试范围当然是越小越好——高内聚低耦合的模块只需要测试新增功能而不需要回归原有功能。对产品来说，需求上线的时间当然是越短越好——高内聚低耦合的设计能减少开发和测试的工作量，上线时间自然也就变短了。对用户来说，系统问题当然是越少越好——高内聚低耦合的设计至少能保证老代码正常运行，不会因为新功能而莫名崩溃。
你好了不？
缺点
优点如此显而易见，为什么实际工作中很少有人认真执行“高内聚低耦合”的设计要求呢？
如果你是一个政府部门，你是愿意自己只盖一个章、让用户去跑其它部门盖完剩下的十几个章，还是愿意让用户只来你这一个部门、你去跑其它部门改完所有的章？如果你是一家商店，你是愿意让用户把钱全都花在你的店里，还是愿意提供一堆服务让用户去别的店铺消费？做软件设计也要面对“投入产出比”的考虑。如果一个良好设计的成本太高而收益太低、甚至与主要目标背道而驰，那么人们自然就会用脚投票、不使用这种设计。
前几年这种漫画没少见吧
“高内聚低耦合”的设计就常常会陷入这样的困境中。首先，要严格做到高内聚、低耦合，通常多要付出很多精力来做设计，还常常会增加不少的开发工作量。而这些额外成本有时并不一定能带来期望的结果。以前面说的短信验证功能模块为例，如果五种业务逻辑的差异都只有一两行代码，那么全用if-else的方式放在一个类中会是一种更合适的方法。但是，如果业务逻辑本身比较复杂、或者彼此之间差异比较大，还用if-else处理的话，最后代码会变成一团乱麻、快速腐化。因此，尽管我们的设计多了六个类（一个业务分发类、五个不同的业务处理类），并导致了前期开发时多花了一天半天的时间，但整个模块的可维护性、可扩展性都有很大提高，可以说是“过当”了吧。
这是短信验证模块目前的类图
其次，“高内聚低耦合”是一种原则性的设计准则。在现实中，原则性的东西一般都会为灵活性——比如工期啦，历史遗留问题啦，部门关系啦——让步。我曾经经常听到“以前就是这么做的，这次也这样处理吧”、“他们的接口就是这样的，我们也没办法”这样的话，也经常看到因为这些原因而放弃更好的设计，甚至因此而不再思考有没有更好的设计。有时真让人感叹技术其实什么都改变不了。另外，原则性的东西往往太务虚而无法落到实处。“这个模块不够高内聚”，“这段代码的耦合度太高了”，具体是怎么不够高内聚？要改成怎样才能降低耦合度？完全叫人丈二金刚摸不着头脑。最后，法学上有种罪名叫做“箩筐罪”，当你觉得一个东西有问题、但又说不清楚具体是什么问题时，就可以把它归入“箩筐罪”中——也就是所谓“xx罪是个框，什么都能往里装”。“高内聚低耦合”可以说是软件设计界的“箩筐罪”，只要想往里装就能往里装。例如前面那个短信验证功能模块，它真的满足了“高内聚低耦合”了吗？虽然经过精心设计，但是如果要挑，也还能挑出一箩筐毛病来。所以，“高内聚低耦合”的度很难把握，过于执着甚至可能走火入魔。这也是为什么“高内聚低耦合”很少在实际工作中提及和应用的原因之一。
原则和实践……常常就是这么残酷
HOW
有些问题可以靠技术来解决。例如，开发成本高这个问题在团队开发水平提高到一定层次之后就迎刃而解了；太过务虚的问题也可以通过学习和掌握SOLID、设计模式等具体的设计技能来解决。这些具体的技术会在以后慢慢讨论。但是非技术的问题——例如历史包袱、部门关系等，我就爱莫能助了。
高内聚低耦合与抽象
虽然高内聚低耦合有上面这些问题，但是，在做业务抽象的设计时，我们还是要认真考虑、并遵守这个原则。因为高内聚低耦合不仅是做好设计的途径、也是评价设计好坏的标准：对于面向对象的业务抽象设计来说更是如此。
A good business abstract must be able to express themselves "what" or "what can you do," and hide themselves "how to do." High cohesion, low coupling concept is suitable to make business abstraction to hide their implementation details. If a business is not abstract or excessive coupling cohesion, it will be too much to their implementation details leak out. Remember QueryService appear in the "abstract" a text it? It queryFromRemote and queryFromLocal exposed to external business abstraction, resulting in inconvenience when using the interface, which is not high enough cohesive result. There ExcelService, this interface with the 2003 version of Excel file format excessive coupling, and the results can not be successfully upgraded to version 20007 Excel.