什么时候提高程序凝聚力会恶化耦合？

Question

我最近参加了一个设计原则和模式的考试，考试中的一个问题是：“有时提高程序内聚可能会恶化耦合，举个例子。”

据我了解，凝聚力是指一个类/模块在解决它所创建的问题上的专注程度，或者更好的是，它在完成工作方面的表现如何。它做不该做的工作吗？然后将该部分移动到不同的类/模块。

耦合是许多类/模块之间的依赖级别。这意味着无论我们是否对不同的模块/类进行重大更改，一个好的类/模块都会起作用。

我用来向自己解释这一点的一种方式是这个例子： 调酒师的工作是制作咖啡和其他饮料。一个好的调酒师应该做好他的工作，那就是煮咖啡，这会增加他的凝聚力，但如果他开始拖地并为顾客服务，他就会脱离工作，从而失去凝聚力。一个好的调酒师也不应该受到其他工作人员的影响，这意味着他的耦合度很低。换句话说，如果清洁工一天早上不来上班，他的工作应该不受影响。

所以如果我的理解是正确的，这意味着增加内聚不应该对耦合产生负面影响，就像告诉调酒师更多地专注于咖啡不会让他更依赖清洁工一样。

我错过了什么吗？我对内聚/耦合的理解有缺陷吗？抱歉读了这么久！

Answer 1

如果酒吧的员工非常有凝聚力，他们就会了解彼此的工作，并且可以更有效地作为一个团队工作。例如，鸡尾酒女服务员可能知道调酒师喜欢在哪里取回脏盘子（靠近洗碗机的酒吧部分），所以女服务员会将空杯子放在那里。或者经理可能会注意到调酒师的冰块越来越少，然后到房子后面去拿更多的，然后在不需要问的情况下重新加满。

当然，通过了解彼此的工作，现在员工之间的耦合更加紧密。这可能意味着流程的任何变化都会影响更多的人并产生培训问题。例如，如果酒吧决定从冰块换成碎冰，则必须告知经理，否则他可能会买错冰块。如果团队松散耦合，则只有调酒师需要知道。

从这个示例中，您可以看到一个非常有凝聚力的团队需要了解彼此的工作，这使得改变任何个人工作变得更加困难。这对应于软件中紧密耦合的模块造成的可维护性问题。这很方便，并且可以让模块更紧密地协同工作，但如果事情发生变化，就会产生问题。