什么是“中低耦合和凝聚力高”是什么意思什么是“中低耦合和凝聚力高”是什么意思(What does &

我理解的语句问题low in coupling and high in cohesion 。 我用Google搜索和阅读了很多关于这一点，但仍然发现很难理解。

以我的理解是High cohesion的手段，我们应该有一个专门以执行特定功能的类。 希望这是正确的吗？ 像信用卡验证类，这是专门来验证只有信用卡。

而且还是不明白什么低耦合意味着什么？

Answer 1:

我相信是这样的：

凝聚是指到一个模块/类的元素属于一起的程度，故建议相关的代码应当是相互接近，所以我们应该力求高凝聚力和所有相关的代码结合在一起尽可能接近。 它与模块/类中的元素做。

耦合是指到不同的模块/类互相依赖的程度，因此建议所有模块应尽量独立，这就是为什么低耦合。 它具有与不同模块/类之间的元件做。

为了形象化整个画面会有所帮助：

该截图是取自Coursera 。

Answer 2:

凝聚在软件工程，在现实生活中，是由一个整体的元素多少（在我们的例子让我们说一个类），可以说它们实际上属于一起。 因此，它是每一块的功能如何强烈相关由软件模块的源代码中表达的度量。

在面向对象的角度来看待凝聚力的一种方法是，如果在类中的方法所使用的任何私有属性。

现在讨论的是比这高 ，但接应 （或凝聚力的最佳类型-功能内聚）更大的是，当一个模块的部分进行分组，因为他们都在模块的定义明确的任务作出贡献。

用通俗的话说耦合 ，是多少钱一个组件（再次，想象一类，虽然不一定）知道的内部运作或另外一个内部元素，也就是说，它多少知识有其他成分的。

松散耦合是使那些组件，彼此依赖于实际可能最低程度的系统或网络互连组件的方法...

我写了一篇博客文章这件事。 它讨论这一切的细节和例子等。这也解释了为什么你应该遵循这些原则的好处。

Answer 3:

在软件设计高内聚意味着类应该做的一两件事，一件事非常好。 高内聚性是密切相关的单一职责原则 。

低耦合建议类应该有尽可能少的依赖。 此外，必须存在要弱依赖依赖 - 更喜欢具体的类对接口的依赖，而不是依赖，还是更喜欢在组成继承。

高内聚，低耦合给我们更好的设计的代码更易于维护。

Answer 4:

低耦合是在两个或多个模块的上下文。 如果在其它模块的许多变化一个模块的结果的变化，则它们被说成是高度耦合。 这是基于接口的编程帮助。 它们之间的接口（相互作用的平均值）并没有改变模块内的任何变化将不会影响其他模块。

高cohesion-把类似的东西一起。 因此，一个类应该有方法或行为做相关的工作。 只给一个夸张的坏例子：List接口的实现不应该有相关的字符串操作。 String类应该有方法，这是相关的弦乐，同样，列表的实施应该有相应的东西领域。

希望帮助。

Answer 5:

简短而明确的答案

• 高内聚 ：一个类内部的元素/模块应属于功能一起，做一个特别的事情。
• 松耦合 ：其中不同的类/模块应该是最小的依赖性。

Answer 6:

长话短说，低耦合，因为我明白这意味着组件可以在不影响系统的正常运作被交换出去。 Basicaly modulize系统成可以单独不会破坏系统更新功能部件

Answer 7:

你有智能手机吗？ 有一个大的应用程序或大量的小家伙吗？ 在另一个没有一个应用程序回复？ 你可以使用一个应用程序在安装，更新和/或卸载其他？ 每个应用程序是自包含的高凝聚力。 每个应用程序都独立于其他的低耦合。 DevOps的赞成这种架构，因为这意味着你可以做离散的连续部署，而无需中断系统的全。

Answer 8:

低耦合和高聚合是推荐的现象。

耦合是指在何种程度上各个模块相互依存，其他模块如何影响上改变模块的一些/相当的功能。 低耦合强调作为依赖必须保持低，使得非常至少/可忽略的变化以其他模块制成。

Answer 9:

一个例子可能会有帮助。 想象其生成数据并将其放入的数据存储器，无论是在磁盘或一个数据库中的文件的系统。

高内聚可以通过从数据生产代码单独数据存储码来实现。 （事实上​​分离从数据库存储在磁盘存储）。

低耦合可以通过确保数据生产不具有数据存储的任何不必要的知识（如不问的文件名或数据库连接的数据存储）来实现。

Answer 10:

继承或概括是高的耦合（即，高相互依存）的一个例子。 我的意思的，这是在继承往往是父类定义了用于其子类，并改变父类的方法直接影响它的子类的基础功能。 因此，我们可以说，有类之间相互依赖的程度更大。

实现或者使用接口是高内聚（即，低的相互依赖）的一个例子。 这意味着，一个接口提出了合同，实现它的任何类，但每个类都有实现自己的方式和接口声明的方法在一个类中声明的方法的变化不影响任何其他类的权利。

Answer 11:

下面是从一个位的一个抽象的答案，图论角：

让我们只看状态的对象之间（执导）的依赖关系图简化问题。

一个非常简单的答案可以通过考虑两个来说明限制的情况下依赖图：

首届极限情况 ：一丛图表 。

群集图是一个高内聚和低偶联（给定一组的簇大小的）依赖图的最完美的实现。

簇之间的依赖关系是最大的（完全连接），和簇间的依赖最小（零）。

这是的一个答案的抽象插图极限情况 。

第二届极限情况是完全连通图，这里一切都取决于一切。

现实是介于两者之间，越接近集群图形向好，在我的卑微的理解。

从另一个角度来看 ：在一个有向依赖图看时，理想地应该是无环的，如果不是则循环形成最小的簇/组件。

一步向上/向下的层次结构对应松散耦合，紧凝聚力对“一个实例”在软件，但也可以查看此松耦合/致密凝聚原理在一个非循环有向图的不同深度的重复现象（或上其生成树的之一）。

一个系统到层次结构的这种分解有助于战胜指数的复杂性（比如每个集群有10种元素）。 然后，在6层，它已经是百万对象：

10簇形成1个超聚类，10个超团形式1 hypercluster等等...不紧的凝聚力，松散耦合的概念，这样的分级结构将是不可能的。

所以这可能只是故事的两层中的真正的重要性，而不仅仅是高内聚低耦合。 考虑更高层次的抽象和它们之间的相互作用时，真正的重要性变得清晰。

Answer 12:

凝聚力 -为彼此如何密切相关的一切。
耦合 -一切是如何相互连接。

让我们看一个例子 - 我们要设计一个自动驾驶汽车。

（1）我们需要电动机正常运行。

（2）我们需要的车来车往自身。

所有（1）启动电机，使之运行工作大起来的类和功能，但不利于汽车转向。 所以我们把落后的发动机控制装置的类。

所有的类和函数（2）工作的伟大，使汽车转向，加速和制动。 他们不利于汽车启动或发送汽油活塞。 所以我们把落后自身的驱动控制器这些类。

这些控制器用于与所有可用的类和函数的通信。 控制器然后仅与彼此通信。 这意味着我不能把从油门踏板类活塞类的功能，使车跑得更快。

踏板类有问驱动控制器交谈的引擎控制器，然后告诉活塞类走得更快。 这让我们的程序员能够找到问题，并允许我们大型程序，而不必担心相结合。 这是因为代码是所有工作的幕后控制人。

文章来源: What does 'low in coupling and high in cohesion' mean