What does 'low in coupling and high in cohesion' mean
我在理解语句
据我了解，
仍然不了解低耦合是什么意思？
我相信的是：
内聚性是指模块/类的元素相互之间的结合程度，建议相关代码应彼此靠近，因此我们应争取较高的内聚性，并尽可能将所有相关代码绑定在一起。它与模块/类中的元素有关。
耦合是指不同模块/类之间相互依赖的程度，建议所有模块都应尽可能独立，这就是低耦合的原因。它与不同模块/类中的元素有关。
可视化整个图片将有所帮助：
屏幕截图取自Coursera。
就像在现实生活中一样，软件工程的凝聚力是可以说组成一个整体(在我们的情况下，我们说一个类)的元素实际上属于同一元素的程度。因此，它衡量了由软件模块的源代码表达的每个功能之间的关联程度。
从OO角度看内聚的一种方法是，如果类中的方法使用任何私有属性。
现在讨论的范围比这个要大，但是高内聚力(或内聚力的最佳类型-功能内聚力)是将模块的各个部分进行分组的原因，因为它们都对模块的一个明确定义的任务有所贡献。
简单来说，耦合就是一个组件(再次设想一个类，尽管不一定)想知道另一个组件的内部工作原理或内部元素，即它对另一个组件有多少知识。
松散耦合是一种将系统或网络中的组件互连的方法，以使这些组件在实际可行的范围内相互依存程度最小……
我写了一篇关于这个的博客文章。它通过示例等详细讨论了所有这些内容。它还解释了为什么遵循这些原则的好处。
在软件设计中，高凝聚力意味着类应该很好地完成一件事和一件事。高凝聚力与单一责任原则密切相关。
低耦合表明类应该具有最小的依赖关系。另外，必须存在的依赖项应该是弱的依赖项-优先考虑接口的依赖性，而不是具体类的依赖性，或者优先于继承而不是继承。
高内聚和低耦合为我们提供了更好设计的代码，更易于维护。
简短明了的答案
- 高凝聚力：一个类/模块中的元素应该在功能上属于同一类，并且做一件特定的事情。
- 松耦合：在不同的类/模块之间应该有最小的依赖性。
低耦合是在两个或多个模块的上下文中。如果一个模块的更改导致另一模块的许多更改，则可以说它们是高度耦合的。这是基于接口的编程帮助的地方。模块内的任何更改都不会影响其他模块，因为它们之间的接口(交互作用的平均值)没有更改。
高凝聚力-将类似的东西放在一起。因此，一个类应该具有方法或行为来完成相关工作。举一个夸张的坏例子：List接口的实现不应具有与String相关的操作。 String类应具有与String相关的方法，字段，并且类似地，List的实现应具有相应的内容。
希望能有所帮助。
长话短说，低耦合，据我所知，这意味着可以交换组件而不会影响系统的正常运行。基本上将您的系统调制为可以正常更新的功能组件，而无需中断系统
你有智能手机吗？有一个大应用程序还是有很多小应用程序？一个应用程序会回复另一个吗？您可以在安装，更新和/或卸载另一个应用程序时使用一个应用程序吗？每个应用程序都是独立的，具有很高的凝聚力。每个应用程序独立于其他应用程序是低耦合的。 DevOps支持此体系结构，因为它意味着您可以执行离散的连续部署，而不会破坏整个系统。
凝聚力-一切之间的紧密联系。
耦合-一切之间如何相互连接。
让我们举个例子-我们要设计一种自动驾驶汽车。
(1)我们需要电动机正常运行。
(2)我们需要汽车自行驾驶。
(1)中的所有类和功能都可以使电动机启动并使电动机一起运转，但不会帮助汽车转向。因此，我们将这些类放在引擎控制器后面。
(2)中的所有类和功能都可以使汽车转向，加速和制动。它们不会帮助汽车启动或将汽油输送到活塞。因此，我们将这些类放置在其自己的Driving Controller之后。
这些控制器用于与所有可用的类和功能进行通信。然后，控制器仅相互通信。这意味着我无法从油门踏板类中调用活塞类中的函数来使汽车行驶更快。
踏板课程必须要求驾驶控制器与发动机控制器对话，然后告诉发动机控制器更快地行驶。这使我们的程序员能够发现问题，并使我们能够组合大型程序而不必担心。这是因为代码都在控制器后面工作。
继承或泛化是高度耦合(即高度相互依赖)的一个示例。我的意思是，在继承中，父类通常会定义其子类使用的基本功能，并且父类的方法更改会直接影响其子类。因此，我们可以说类之间存在更大程度的相互依赖。
实现或使用接口是高内聚性(即低相互依赖性)的一个示例。这意味着接口为实现它的任何类提出了合同，但是每个类都有权以自己的方式实现在接口中声明的方法，并且在一个类中声明的方法的更改不会影响其他任何类。
这是一个抽象的图形理论角度的答案：
让我们通过仅查看有状态对象之间的(定向)依赖图来简化问题。
通过考虑依赖图的两种限制情况，可以说明一个非常简单的答案：
第一种极限情况：集群图。
聚类图是高内聚和低耦合(给定的聚类大小)依赖性图的最完美实现。
群集之间的依赖性最大(完全连接)，群集间的依赖性最小(零)。
这是其中一种极限情况下答案的抽象图示。
第二个极限情况是一个完全连通的图，其中一切都取决于一切。
在我的愚见中，现实介于两者之间，离簇图越近越好。
从另一个角度来看：当查看有向依存关系图时，理想情况下它应该是非循环的，如果不是这样，则循环会形成最小的群集/组件。
层次结构的上/下一级对应于松耦合，紧密内聚的"一个实例"，但是可以将这种松耦合/紧密内聚的原理视为在无环有向图的不同深度处重复的现象(或其生成树之一)。
将系统分解为层次结构有助于克服指数级的复杂性(例如，每个集群有10个元素)。然后在6层，已经是100万个对象：
10个集群构成1个超集群，10个集群构成1个超集群，依此类推...如果没有紧密的凝聚力，松散耦合的概念，那么这种分层体系结构将是不可能的。
因此，这可能是故事的真正重要性，而不仅仅是两个层中的高内聚性低耦合。在考虑更高级别的抽象及其交互时，真正的重要性变得很明显。
一个例子可能会有所帮助。想象一下一个系统，该系统生成数据并将其放入数据存储，可以是磁盘上的文件，也可以是数据库。
通过将数据存储代码与数据生产代码分开，可以实现高内聚性。 (实际上是将磁盘存储与数据库存储分开)。
通过确保数据生产对数据存储没有任何不必要的了解(例如，不询问数据存储有关文件名或数据库连接的信息)，可以实现低耦合。
低耦合和高内聚是推荐现象。
耦合是指各个模块在多大程度上相互依赖，以及其他模块在更改某个模块的某些/重要功能时如何受到影响。强调低耦合，因为必须保持较低的依存关系，以便对其他模块进行非常小/可忽略的更改。
低耦合：
将使它非常简单。
如果更改模块，它将如何影响其他模块。
例：-
如果您的服务API公开为JAR，则对方法签名的任何更改都将中断调用API(高/紧耦合)。
如果您的模块和其他模块通过异步消息进行通信。只要您收到消息，您的方法更改签名就将在模块本地(低耦合)。
偏离航路时，如果消息格式发生更改，则呼叫客户端将需要进行一些更改。
我认为您的定义太多了，但是如果您仍然有疑问，或者如果您是编程新手并且想要深入了解它，那么我建议您观看此视频，
它只是获得更多有关多态性信息的参考...
希望您对此有所了解