我理解这种低耦合高内聚的说法有问题。我在谷歌上搜索并阅读了很多这方面的内容,但还是觉得很难理解。
我的理解是,高内聚意味着,我们应该有专门执行特定功能的类。希望这是正确的?比如信用卡验证类,它专门用于验证信用卡。
还是不明白低耦合是什么意思?
我理解这种低耦合高内聚的说法有问题。我在谷歌上搜索并阅读了很多这方面的内容,但还是觉得很难理解。
我的理解是,高内聚意味着,我们应该有专门执行特定功能的类。希望这是正确的?比如信用卡验证类,它专门用于验证信用卡。
还是不明白低耦合是什么意思?
当前回答
简短明了的回答
高内聚性:一个类/模块中的元素应该在功能上属于一起,并做一件特定的事情。 松耦合:不同的类/模块之间应该有最小的依赖关系。
其他回答
低耦合是在两个或多个模块的上下文中。如果一个模块中的变化导致其他模块中的许多变化,那么它们被称为高度耦合的。这就是基于接口的编程的用处。模块内的任何变化都不会影响其他模块,因为它们之间的接口(交互的平均值)没有改变。
高内聚性——把相似的东西放在一起。所以一个类应该有方法或行为来做相关的工作。举一个夸张的坏例子:List接口的实现不应该有与String相关的操作。String类应该有方法和与String相关的字段,类似地,List的实现应该有相应的东西。
希望这能有所帮助。
低耦合:—— 让它变得简单。 如果你改变了你的模块,它对其他模块有什么影响?
例子:- 如果您的服务API公开为JAR,对方法签名的任何更改都将破坏调用API(高/紧耦合)。
如果您的模块和其他模块通过异步消息通信。只要您获得消息,您的方法更改签名将是您模块的本地(低耦合)。
如果消息格式发生变化,则呼叫客户端将需要进行一些更改。
在软件工程中,就像在现实生活中一样,内聚是指组成一个整体(在我们的例子中,让我们说一个类)的元素实际上属于一起的数量。因此,它是软件模块的源代码所表达的每个功能之间相关性的一种度量。
从OO的角度来看内聚的一种方法是类中的方法是否使用任何私有属性。
现在讨论的范围更大了,但高内聚(或内聚的最佳类型-功能内聚)是指模块的各个部分被分组,因为它们都有助于模块的一个定义良好的任务。
简单地说,耦合就是一个组件(再一次,想象一个类,尽管不一定)对另一个组件的内部工作方式或内部元素的了解程度,即它对另一个组件的了解程度。
松耦合是一种将系统或网络中的组件相互连接的方法,这样这些组件就可以在实际可能的最小程度上相互依赖。
我为此写了一篇博客。它详细地讨论了所有这些,并提供了示例等。它还解释了为什么应该遵循这些原则的好处。
下面是一个从抽象的图论角度给出的答案:
让我们通过只查看有状态对象之间的(有向)依赖关系图来简化这个问题。
一个极其简单的答案可以通过考虑依赖图的两种限制情况来说明:
第一个极限情况:聚类图。
簇图是高内聚低耦合(给定一组簇大小)依赖图的最完美实现。
簇之间的依赖性是最大的(完全连接),而簇间的依赖性是最小的(零)。
这是一种极限情况下答案的抽象说明。
第二个极限情况是一个全连通图,其中所有东西都依赖于所有东西。
在我看来,现实情况介于两者之间,越接近聚类图越好。
从另一个角度来看:当观察有向依赖关系图时,理想情况下它应该是无循环的,如果不是,那么循环就会形成最小的集群/组件。
层次结构的上升/下降对应于软件中松耦合、紧密内聚的“一个实例”,但可以将这种松耦合/紧密内聚原则视为在无环有向图(或其生成树之一)的不同深度上的重复现象。
将系统分解为层次结构有助于克服指数级的复杂性(比如每个集群有10个元素)。在6层中,已经有100万个对象了:
10个星系团形成1个超星系团,10个超星系团形成1个超星系团……如果没有紧密内聚、松散耦合的概念,这样的层次结构就不可能实现。
所以这可能是故事的真正重要性,而不仅仅是两层中的高内聚低耦合。当考虑更高级别的抽象及其交互时,真正的重要性变得清晰起来。
你有智能手机吗?有一个大的还是很多小的应用程序?一个应用程序是否会回复另一个应用程序?您可以在安装、更新和/或卸载另一个应用程序时使用一个应用程序吗?每个应用程序都是独立的,这是一种高内聚性。每个应用程序都独立于其他应用程序,这是低耦合。DevOps偏爱这种架构,因为这意味着您可以在不中断整个系统的情况下进行离散的连续部署。