我理解这种低耦合高内聚的说法有问题。我在谷歌上搜索并阅读了很多这方面的内容，但还是觉得很难理解。
我的理解是，高内聚意味着，我们应该有专门执行特定功能的类。希望这是正确的?比如信用卡验证类，它专门用于验证信用卡。
还是不明白低耦合是什么意思?
当前回答
低耦合:—— 让它变得简单。 如果你改变了你的模块，它对其他模块有什么影响?
例子:- 如果您的服务API公开为JAR，对方法签名的任何更改都将破坏调用API(高/紧耦合)。
如果您的模块和其他模块通过异步消息通信。只要您获得消息，您的方法更改签名将是您模块的本地(低耦合)。
如果消息格式发生变化，则呼叫客户端将需要进行一些更改。
其他回答
下面是一个从抽象的图论角度给出的答案:
让我们通过只查看有状态对象之间的(有向)依赖关系图来简化这个问题。
一个极其简单的答案可以通过考虑依赖图的两种限制情况来说明:
第一个极限情况:聚类图。
簇图是高内聚低耦合(给定一组簇大小)依赖图的最完美实现。
簇之间的依赖性是最大的(完全连接)，而簇间的依赖性是最小的(零)。
这是一种极限情况下答案的抽象说明。
第二个极限情况是一个全连通图，其中所有东西都依赖于所有东西。
在我看来，现实情况介于两者之间，越接近聚类图越好。
从另一个角度来看:当观察有向依赖关系图时，理想情况下它应该是无循环的，如果不是，那么循环就会形成最小的集群/组件。
层次结构的上升/下降对应于软件中松耦合、紧密内聚的“一个实例”，但可以将这种松耦合/紧密内聚原则视为在无环有向图(或其生成树之一)的不同深度上的重复现象。
将系统分解为层次结构有助于克服指数级的复杂性(比如每个集群有10个元素)。在6层中，已经有100万个对象了:
10个星系团形成1个超星系团，10个超星系团形成1个超星系团……如果没有紧密内聚、松散耦合的概念，这样的层次结构就不可能实现。
所以这可能是故事的真正重要性，而不仅仅是两层中的高内聚低耦合。当考虑更高级别的抽象及其交互时，真正的重要性变得清晰起来。
我的信念是:
内聚性是指一个模块/类的元素属于在一起的程度，建议相关的代码应该相互接近，因此我们应该争取高内聚性，并将所有相关的代码尽可能紧密地绑定在一起。它与模块/类中的元素有关。
耦合是指不同模块/类之间相互依赖的程度，建议所有模块尽可能独立，这就是低耦合的原因。它与不同模块/类之间的元素有关。
将整个画面形象化是有帮助的:
截图来自Coursera。
低耦合:—— 让它变得简单。 如果你改变了你的模块，它对其他模块有什么影响?
例子:- 如果您的服务API公开为JAR，对方法签名的任何更改都将破坏调用API(高/紧耦合)。
如果您的模块和其他模块通过异步消息通信。只要您获得消息，您的方法更改签名将是您模块的本地(低耦合)。
如果消息格式发生变化，则呼叫客户端将需要进行一些更改。
举个例子可能会有所帮助。想象一个生成数据并将其放入数据存储的系统，数据存储可以是磁盘上的文件，也可以是数据库。
高内聚可以通过将数据存储代码与数据生产代码分开来实现。(实际上是将磁盘存储与数据库存储分开)。
低耦合可以通过确保数据生产对数据存储没有任何不必要的了解来实现(例如，不会询问数据存储关于文件名或db连接的信息)。
当我读到微服务的时候。我发现了以下几点:
内聚性是对组件各部分之间的关系数量的度量。高内聚性意味着交付组件功能所需的所有部分都包含在组件中
耦合是系统中一个组件与其他组件之间关系数量的度量。低耦合意味着组件与其他组件之间没有太多关系
