我理解这种低耦合高内聚的说法有问题。我在谷歌上搜索并阅读了很多这方面的内容，但还是觉得很难理解。
我的理解是，高内聚意味着，我们应该有专门执行特定功能的类。希望这是正确的?比如信用卡验证类，它专门用于验证信用卡。
还是不明白低耦合是什么意思?
我的信念是:
内聚性是指一个模块/类的元素属于在一起的程度，建议相关的代码应该相互接近，因此我们应该争取高内聚性，并将所有相关的代码尽可能紧密地绑定在一起。它与模块/类中的元素有关。
耦合是指不同模块/类之间相互依赖的程度，建议所有模块尽可能独立，这就是低耦合的原因。它与不同模块/类之间的元素有关。
将整个画面形象化是有帮助的:
截图来自Coursera。
低耦合和高内聚是一个值得推荐的现象。
耦合意味着各个模块相互依赖的程度，以及其他模块在改变模块的某些/相当大的功能时是如何受到影响的。低耦合被强调，因为依赖关系必须保持在较低的水平，以便对其他模块进行非常少的/可以忽略不计的更改。
低耦合是在两个或多个模块的上下文中。如果一个模块中的变化导致其他模块中的许多变化，那么它们被称为高度耦合的。这就是基于接口的编程的用处。模块内的任何变化都不会影响其他模块，因为它们之间的接口(交互的平均值)没有改变。
高内聚性——把相似的东西放在一起。所以一个类应该有方法或行为来做相关的工作。举一个夸张的坏例子:List接口的实现不应该有与String相关的操作。String类应该有方法和与String相关的字段，类似地，List的实现应该有相应的东西。
希望这能有所帮助。
在软件工程中，就像在现实生活中一样，内聚是指组成一个整体(在我们的例子中，让我们说一个类)的元素实际上属于一起的数量。因此，它是软件模块的源代码所表达的每个功能之间相关性的一种度量。
从OO的角度来看内聚的一种方法是类中的方法是否使用任何私有属性。
现在讨论的范围更大了，但高内聚(或内聚的最佳类型-功能内聚)是指模块的各个部分被分组，因为它们都有助于模块的一个定义良好的任务。
简单地说，耦合就是一个组件(再一次，想象一个类，尽管不一定)对另一个组件的内部工作方式或内部元素的了解程度，即它对另一个组件的了解程度。
松耦合是一种将系统或网络中的组件相互连接的方法，这样这些组件就可以在实际可能的最小程度上相互依赖。
我为此写了一篇博客。它详细地讨论了所有这些，并提供了示例等。它还解释了为什么应该遵循这些原则的好处。
在软件设计中，高内聚性意味着类应该做一件事，并且把一件事做得很好。高凝聚力与单一责任原则密切相关。
低耦合意味着类应该具有最少的依赖关系。而且，必须存在的依赖关系应该是弱依赖关系——喜欢对接口的依赖而不是对具体类的依赖，或者喜欢组合而不是继承。
高内聚和低耦合使我们能够更好地设计代码，从而更容易维护。
举个例子可能会有所帮助。想象一个生成数据并将其放入数据存储的系统，数据存储可以是磁盘上的文件，也可以是数据库。
高内聚可以通过将数据存储代码与数据生产代码分开来实现。(实际上是将磁盘存储与数据库存储分开)。
低耦合可以通过确保数据生产对数据存储没有任何不必要的了解来实现(例如，不会询问数据存储关于文件名或db连接的信息)。
继承或泛化是高耦合(即高度相互依赖)的一个例子。我这么说的意思是，在继承中，父类通常定义了它的子类使用的基本功能，父类方法的更改直接影响它的子类。因此，我们可以说，阶级之间有更大程度的相互依赖。
实现或使用接口是一个高内聚(即低相互依赖)的例子。这意味着接口为实现它的任何类提出了契约，但每个类都有权以自己的方式实现接口中声明的方法，并且一个类中声明的方法的更改不会影响任何其他类。
你有智能手机吗?有一个大的还是很多小的应用程序?一个应用程序是否会回复另一个应用程序?您可以在安装、更新和/或卸载另一个应用程序时使用一个应用程序吗?每个应用程序都是独立的，这是一种高内聚性。每个应用程序都独立于其他应用程序，这是低耦合。DevOps偏爱这种架构，因为这意味着您可以在不中断整个系统的情况下进行离散的连续部署。
内聚性-所有事物之间的紧密联系。 耦合-所有事物如何相互连接。
让我们举个例子——我们想设计一辆自动驾驶汽车。
我们需要马达正常运转。
我们需要这辆车能自动行驶。
(1)中的所有类和函数都能很好地一起启动电机并使其运行，但不能帮助汽车转向。所以我们把这些类放在引擎控制器后面。
(2)中的所有类和函数都能很好地使汽车转向、加速和制动。它们不能帮助汽车启动或将汽油输送到活塞。所以我们把这些类放在它自己的驱动控制器后面。
这些控制器用于与所有可用的类和函数通信。控制器之间只进行通信。这意味着我不能从油门踏板类中调用活塞类中的函数来使汽车走得更快。
踏板类必须要求驱动控制器与引擎控制器对话，然后引擎控制器告诉活塞类加快速度。这使得我们程序员能够发现问题，并允许我们毫无顾虑地组合大型程序。这是因为代码都是在控制器后面工作的。
下面是一个从抽象的图论角度给出的答案:
让我们通过只查看有状态对象之间的(有向)依赖关系图来简化这个问题。
一个极其简单的答案可以通过考虑依赖图的两种限制情况来说明:
第一个极限情况:聚类图。
簇图是高内聚低耦合(给定一组簇大小)依赖图的最完美实现。
簇之间的依赖性是最大的(完全连接)，而簇间的依赖性是最小的(零)。
这是一种极限情况下答案的抽象说明。
第二个极限情况是一个全连通图，其中所有东西都依赖于所有东西。
在我看来，现实情况介于两者之间，越接近聚类图越好。
从另一个角度来看:当观察有向依赖关系图时，理想情况下它应该是无循环的，如果不是，那么循环就会形成最小的集群/组件。
层次结构的上升/下降对应于软件中松耦合、紧密内聚的“一个实例”，但可以将这种松耦合/紧密内聚原则视为在无环有向图(或其生成树之一)的不同深度上的重复现象。
将系统分解为层次结构有助于克服指数级的复杂性(比如每个集群有10个元素)。在6层中，已经有100万个对象了:
10个星系团形成1个超星系团，10个超星系团形成1个超星系团……如果没有紧密内聚、松散耦合的概念，这样的层次结构就不可能实现。
所以这可能是故事的真正重要性，而不仅仅是两层中的高内聚低耦合。当考虑更高级别的抽象及其交互时，真正的重要性变得清晰起来。
我想你们已经有了很多定义，但如果你们仍然有疑问，或者如果你们是编程新手，想深入了解这个问题，那么我建议你们看这个视频， https://youtu.be/HpJTGW9AwX0 这只是一个参考，以获得更多关于多态性的信息… 希望你能更好地理解这一点
低耦合:—— 让它变得简单。 如果你改变了你的模块，它对其他模块有什么影响?
例子:- 如果您的服务API公开为JAR，对方法签名的任何更改都将破坏调用API(高/紧耦合)。
如果您的模块和其他模块通过异步消息通信。只要您获得消息，您的方法更改签名将是您模块的本地(低耦合)。
如果消息格式发生变化，则呼叫客户端将需要进行一些更改。
以旧的PC主板为例。
鼠标有自己的PS/2端口。 打印机有自己的打印机端口。 显示器有自己的VGA端口。
这意味着特定的端口只能用于特定的设备，而不能用于其他设备。
这就是强/高耦合
由于鼠标仅用于操作光标和相关功能，键盘用于输入按键等，即它们只执行它们所要执行的任务，这就是高内聚性
如果鼠标需要输入一些“a”、“b”、“c”按钮，那么它所做的就超过了它应该做的，因为键盘已经在执行它们了，这就是低内聚
幸运的是，专有端口的过时用法被我们称为USB的标准(接口)所取代。这是松散/低耦合
看看这些物理属性，很明显这就是它应该有的样子，但在编写软件时，很容易忘记什么功能应该放在哪里，等等，因此作为一个提醒，在生活中的任何事情中，始终坚持:
“高内聚和松耦合”
当我读到微服务的时候。我发现了以下几点:
内聚性是对组件各部分之间的关系数量的度量。高内聚性意味着交付组件功能所需的所有部分都包含在组件中
耦合是系统中一个组件与其他组件之间关系数量的度量。低耦合意味着组件与其他组件之间没有太多关系
