我最近参加了设计原理＆amp;模式，考试中的一个问题之一是："有时改善程序的凝聚力可能会使耦合恶化，举例说明。"
据我了解，凝聚力是集体/模块的重点是解决它创建的问题，或者更好，或者更好地完成工作。它做不应该做的工作吗？然后将该零件移至其他类/模块。
耦合是许多类/模块之间的依赖程度。这意味着一个好的类/模块都可以正常工作，无论我们是否将重大更改引入了其他模块/类。
我用来向自己解释这一点的一种示例是：调酒师的工作是制作咖啡和其他饮料。一个好的调酒师应该做他的工作，这会造成咖啡，这会增加他的凝聚力，但是如果他开始擦地板并为顾客服务，他就会摆脱工作，因此凝聚力丢失了。好的调酒师也不应受到其他工作人员的影响，这意味着他的耦合较低。我换句话说，如果清洁夫人没有出现在一个早晨上班，他的工作应该不受影响。
因此，如果我的理解是正确的，这意味着增加的凝聚力不应对耦合产生负面影响，就像告诉酒保更多地专注于咖啡更多地不会使他更依赖清洁夫人一样。
我想念什么吗？我对凝聚/耦合的理解是否有缺陷？对不起，长期阅读！
如果酒吧的工作人员非常有凝聚力，他们知道彼此的工作，并且可以更有效地作为一个团队来工作。例如，鸡尾酒女服务员可能知道调酒师喜欢在哪里取回肮脏的菜肴（洗碗机附近的酒吧的一部分），因此女服务员会在那里放下空眼镜。否则经理可能会注意到调酒师在冰上变得越来越低，然后去房屋的后面进行更多补充，而无需被问到。
当然，通过认识彼此的工作，工作人员现在变得更加紧密。这可能意味着任何过程的变化都会影响更多的人并创建培训问题。例如，如果酒吧决定从立方体冰切换为压碎的冰，则必须告诉经理，否则他可能会遇到错误的冰。如果团队松散耦合，只有酒保才需要知道。
在此示例中，您可以看到一个非常有凝聚力的团队需要了解彼此的工作，这使得更难更改任何个人工作。这对应于软件中紧密耦合的模块创建的可维护性问题。它很方便，可以让模块更加紧密地工作，但是如果事情发生了变化，它会产生问题。