abt基石_凝聚力–软件设计的基石

abt基石

凝聚力是软件设计中最重要的概念之一。 凝聚力是绝大多数优秀设计原则和模式的核心，它指导关注点和可维护性的分离。 内聚力（并列耦合）一词由拉里·康斯坦丁（Larry Constantine）在60年代后期作为结构化设计的一部分首次提出，后来由W. Stevens，G。Myers和L. Constantine于1974年更详细地发表。上世纪60年代，70年代和80年代的软件成本，围绕软件设计和可维护性进行了大量的研究和研究。 尽管我们今天仍然可以在网上找到这些论文和研究中的一些，但是它们是在互联网时代之前完成的，在此期间完成的大部分工作要么丢失，要么不容易获得。

但是在深入研究细节之前，让我们先看一些定义。

定义

凝聚力（名词） ：当一个团体或社会的成员团结在一起时。 内聚（形容词）：团结有效地合作。

剑桥词典

在计算机编程中，内聚性是衡量软件模块的各种职责之间相关性和关注程度的度量。

维基百科

内聚性是一个滑动比例尺

一个常见的错误是将内聚性视为二进制属性而不是滑动标度。 在70年代初，史蒂文斯，迈尔斯和君士坦丁的原始作品中，他们定义了七个内聚级别，后来被称为SMC内聚。

由于原始论文是相当久以前写的并且非常学术，所以我们同意，当我们说模块时，我们实际上是在谈论一类或一组函数，而当我们说处理元素时，我们实际上是在谈论方法或函数。

• 巧合（最坏） ：处理元素是任意分组的，没有明显的关系。 处理元素之间没有关系。 例如：更新客户记录，计算贷款付款，打印报告。 巧合的凝聚力在称为Utils或Helpers模块中非常普遍。
• 逻辑 ：在模块级别，处理元素被分组，因为它们属于相关功能的同一逻辑类。 在模块的每次调用中，将调用一个处理元素。 例如：将所有I / O操作，所有数据库操作等分组。在处理元素级别，调用模块传递一个控制标志，并且该标志确定处理元素将调用哪个行为。 例如：一个标志，指示是否应计算折扣，应跳过某种行为等。
• 时间的 ：处理元素在时间上相关。 由于它们在程序执行的特定时间一起被调用，所以它们被分组在一起，但是实际上它们彼此无关。 不同的业务需求可能需要不同的顺序或处理元素的组合。 例如：数据持久性/验证，审核跟踪，通过电子邮件的通知等。
• 程序 ：处理元素按顺序是同一业务部门的一部分，但不共享数据。 将它们分组是因为它们始终遵循一定的执行顺序。 例如：验证用户，处理付款，触发库存库存系统以将采购订单发送给供应商，编写日志。
• 沟通性 ：处理元素有助于使用相同输入或输出的活动。 例如：处理将带一个购物篮并计算折扣，促销，节省的钱，交付成本并返回总价的元素。
• 顺序的 ：当一个处理元素的输出可用作另一处理元素的输入时，对处理元素进行分组。 例如：格式化和验证数据。
• 功能（最佳） ：模块的所有处理元素对于执行单个且定义明确的任务都是必不可少的。 例如：解析XML，根据提供的数据计算保险单的费用。

如果我们采用Meilir Page-Jones在《结构化系统设计实用指南》（1980）上发表的一些想法，我们可能会有一个确定凝聚力水平的指南。

追踪指标

SMC凝聚力模型是70年代迈出的一大步，许多软件专业人士和学者试图创建可以衡量凝聚度的软件指标，以便他们可以以更易于维护的方式设计系统。 SMC凝聚力模型（级别）的问题在于它可能是非常主观的，需要个人判断。 我可以想到一些代码示例，这些代码示例可以适合SMC Cohesion规模中多个级别的内聚。 如果我们开始研究我在上面给出的示例的详细信息，您将发现您对示例属于哪个级别感到怀疑。 由于其主观性，因此无法有效地使用SMC凝聚力来得出可靠的指标。

从70年代末到90年代末，发表了许多论文和几本书，探索并扩展了SMC Cohesion定义的内聚和耦合的概念。 一种获得认可的模型是设计级内聚（DLC）度量。 DLC与SMC非常相似，但只有6级，并且在定义和名称上略有差异。 DLC的主要优点是它更适合于推导度量工具。

在深入探讨DLC级别之前，让我们定义一个词汇表：

• 条件控制：可变v2对可变条件控制依赖v1时v1中作出决定的谓词被使用（如果/ THEN / ELSE），这影响v2的值。
• 迭代控制：与上述相同，但处于循环中（while / for / etc。）

以下是DLC级别：

• 巧合关系（R1） ：模块的两个输出o1和o2既不相互依赖，也不依赖于公共输入。
• 条件关系（R2） ：两个输出的状态控制取决于一个公共输入，或者两个输出之一具有输入的条件控制依赖，另一个具有输入的迭代控制。
• 迭代关系（R3） ：两个输出是迭代控制的，取决于公共输入。
• 通讯关系（R4） ：两个输出取决于一个公共输入。 两个输入之一具有与输入的数据相关性，另一个可以具有控制或数据的相关性。
• 顺序关系（R5） ：一个输出依赖于另一输出。
• 功能（R6） ：模块中只有一个输出。

这六个关系是按顺序排列的，其中R1的凝聚力最弱，R6的凝聚力最强。 在DLC度量定义中，内聚级别由模块输出与处理元素之间的关系确定。

以下是SMC和DLC如何相互关联：

应用凝聚力

根据您所编写的软件类型，您可能需要做出一些妥协。 尽管我们始终应该努力使代码具有最高的内聚性，但是有时这可能会使代码看起来不自然 。 在给定的上下文中，不了解设计原则与自觉不遵循设计原则是有区别的。 我写代码的目的不是要满足那里的每一个设计原则，但是每次我决定不遵循某些原则时，我总是试图有充分的理由。 话虽如此，凝聚力是软件设计的最重要组成部分之一，充分理解它对于编写精心编写的代码至关重要。

如果要构建框架，代码的非常通用的部分或数据转换，则大多数模块和处理元素可能处于顺序和功能级别。 但是，当在商业应用程序（即具有业务逻辑，用户旅程，数据库访问等功能的应用程序）中编写业务规则时，很有可能您的某些模块和处理元素处于通信级别，甚至有些凝聚力较低。 只要这是一个有意识的决定，并且在这种情况下应该做的正确的事，那也是可以的。

有些人将凝聚力与单一责任原则（SRP）进行了比较 。 尽管SRP是一种出色的软件原理，并且完全基于内聚性，但它的范围和主观性都相当狭窄。

确定责任并不总是一件容易的事。 我们需要培养敏锐的眼睛，以发现行为上的细微差异。 当然，如果代码确实是测试驱动的，则对模块进行单元测试可能会帮助我们识别不同的行为。

您的代码的凝聚力越强，则可重用性，健壮性和易于维护性就越高。

资源资源

• 基于规则的计算模块内聚方法
• 软件复杂性：建立统一的耦合和凝聚论
• 软件重组的定量框架
• 使用设计凝聚力可视化，量化和重构软件
• 结构化系统设计实用指南
• 使用UML进行系统分析和设计
• 凝聚力–维基百科
• 单一责任原则

翻译自: https://www.javacodegeeks.com/2016/03/cohesion-cornerstone-software-design.html

abt基石