我最近参加了关于设计原理和模式的考试，考试中的一个问题如下：“举个例子，有时提高程序的凝聚力可能会使耦合恶化。”
据我了解，凝聚力是类/模块专注于解决其创建的问题的能力，或者更好的是，它在完成工作方面有多好。它做了它不应该做的工作吗？然后将其移至其他类/模块。
耦合是许多类/模块之间的依赖级别。意味着无论我们是否对其他模块/类进行重大更改，一个好的类/模块都将起作用。
我以前向自己解释的一种方式是以下示例： 调酒师的工作是煮咖啡和其他饮料。一个好的调酒师应该做好他的工作，即制作咖啡，这会增加他的凝聚力，但是如果他开始擦地板并为顾客服务，他就会脱离工作，从而失去凝聚力。一个好的调酒师也不应受到其他工作人员的影响，这意味着他的耦合度很低。换句话说，如果清洁女工一天早上不露面，他的工作就不会受到影响。
所以，如果我的理解是正确的，这意味着内聚性的提高不会对耦合产生负面影响，就像告诉酒保更多地专注于咖啡不会使他更加依赖清洁女工。
我想念什么吗？我对凝聚力/耦合的理解有缺陷吗？抱歉，长期阅读！
答案 0 :(得分：1)
如果酒吧的员工非常团结，他们就会知道彼此的工作，并且可以更有效地团队合作。例如，一个鸡尾酒女服务员可能知道调酒师喜欢在哪里取回脏盘子（酒吧靠近洗碗机的那部分），因此女服务员会在那里放下空杯子。否则，经理可能会注意到调酒师的冰冻程度越来越低，而无需再被问到，就回到房子的后面以补充更多的酒并将其重新装满。
当然，通过彼此了解工作，现在员工之间的联系更加紧密。这可能意味着过程中的任何更改都会影响更多的人，并造成培训问题。例如，如果酒吧决定从方冰转换为碎冰，则必须告知经理，否则他可能会得到错误种类的冰。如果团队松散耦合，则只有调酒师才需要知道。
从此示例中，您可以看到一个非常团结的团队需要了解彼此的工作，这使得更改任何单个工作变得更加困难。这对应于软件中紧密耦合的模块所造成的可维护性问题。这很方便，可以使模块之间更紧密地协同工作，但是如果事情变了，就会产生问题。