2

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

据我了解,凝聚力是一个类/模块如何专注于解决它为解决而创建的问题,或者更好的是,它在完成这项工作方面有多好。它做不该做的工作吗?然后将该部分移动到不同的类/模块。

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

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

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

我错过了什么吗?我对内聚/耦合的理解有缺陷吗?抱歉读了很久!

4

1 回答 1

1

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

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

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

于 2019-02-27T00:09:23.277 回答