软件构造第五章知识总结

kothiak

已于 2024-06-24 21:06:38 修改

阅读量565

点赞数 16

文章标签： java

于 2024-06-24 21:02:15 首次发布

本文链接：https://blog.csdn.net/kothiak/article/details/139938496

版权

软件设计原则：函数、方法与规约

1. 函数和方法的构成

在软件工程的世界中，函数和方法是构建复杂系统的基本单位。它们是将大型问题分解为可管理的小部分的关键工具，体现了"分而治之"的古老智慧在现代编程中的应用。

1.1 函数的独立性

函数的独立性是模块化编程的核心原则之一。这一原则强调每个函数应该是一个独立的、自包含的单元，能够独立开发、测试和重用。这种独立性不仅提高了代码的可维护性，还大大增强了团队协作的效率。

独立性的三个关键方面：

独立开发：允许不同的开发者并行工作，加速开发过程。
独立测试：便于进行单元测试，提高代码质量和可靠性。
独立重用：促进代码复用，减少冗余，提高系统的整体效率。

函数的独立性与信息隐藏原则密切相关。使用者只需知道函数的接口（即其规约），而无需了解其内部实现细节。这种封装性是面向对象编程的基石，也是构建大型、复杂系统的关键。

1.2 函数的组成部分

一个设计良好的函数通常由两个主要部分构成：规约和实现。这种二元结构反映了抽象和具体、接口和实现之间的基本区别。

1.2.1 规约（Specification）

规约是函数的"契约"，它定义了函数的外部行为和使用方式。一个完整的规约应包含以下要素：

功能描述：简洁明了地说明函数的目的和作用。
函数签名：包括函数名、参数列表和返回类型，是函数的"身份证"。
参数说明：详细解释每个参数的含义、类型和可能的约束条件。
返回值说明：阐明函数返回值的含义和可能的取值范围。
异常说明：列举函数可能抛出的异常及其触发条件。

规约的重要性在于它为函数的使用者和实现者之间搭建了一座桥梁，确保双方对函数的行为有一致的理解。

1.2.2 实现（Implementation）

实现是规约的具体化，它包含了实现函数功能的实际代码。一个好的实现应该：

完全满足规约的要求。
高效、简洁、易于理解。
包含必要的内部注释，解释复杂的算法或非显而易见的代码段。

实现的质量直接影响到函数的性能、可维护性和可靠性。

1.3 函数设计的最佳实践

设计高质量的函数是一门艺术，需要遵循一系列最佳实践：

单一职责原则（SRP）：每个函数应该只做一件事，并且做好。这增加了函数的内聚性，使其更易于理解、测试和维护。
命名规范：函数名应该清晰地表达其功能。好的命名可以大大提高代码的可读性和自文档化程度。
参数限制：函数的参数数量应该保持在一个合理的范围内。过多的参数会增加函数的复杂度和使用难度。
返回值一致性：函数的返回值类型和含义应该保持一致。这有助于避免使用者的困惑和潜在的错误。
错误处理：函数应该优雅地处理各种可能的错误情况，而不是简单地假设一切都会正常运行。
纯函数设计：尽可能设计无副作用的纯函数，这可以提高函数的可预测性和可测试性。
适当的抽象级别：函数应该在正确的抽象级别上操作，既不过于底层也不过于高级。

这些最佳实践不仅有助于创建高质量的个别函数，也是构建健壮、可维护的大型系统的基础。

2. 规约：编程中的沟通桥梁

规约在软件工程中扮演着至关重要的角色，它是开发者之间、开发者与机器之间、甚至是现在与未来的开发者之间的沟通媒介。理解和掌握规约的艺术，是成为优秀软件工程师的关键。

2.1 代码文档的重要性

在软件开发的世界里，代码不仅仅是给机器执行的指令，更是人与人之间交流的媒介。因此，代码文档的重要性怎么强调都不为过。好的文档记录有两个主要目标：面向编译器的信息和面向开发者的信息。

2.1.1 面向编译器的信息

这类信息主要用于帮助编译器进行类型检查、优化和其他静态分析。它包括：

类型声明：明确变量、参数和返回值的数据类型。
修饰符：如final、static等，用于指定特殊的语义。
访问控制：如public、private等，用于控制代码的可见性和封装性。

这些信息不仅帮助编译器捕获潜在的错误，还为开发工具提供了进行智能提示和自动完成的基础。

2.1.2 面向开发者的信息

这类信息旨在帮助人类理解代码的意图、结构和使用方法。它包括：

注释：解释代码的目的、算法的工作原理、复杂逻辑的理由等。
标准化文档：如JavaDoc，提供了一种统一的方式来描述类、方法和字段。
项目级别文档：如README文件，提供项目的概述、安装说明和使用指南。

好的文档不仅有助于其他开发者理解和使用代码，也能帮助未来的自己快速回忆起代码的细节。

2.2 规约作为合同

将规约视为一种合同，这一比喻揭示了规约在软件开发中的核心作用。就像法律合同定义了各方的权利和义务，规约定义了函数实现者和使用者之间的约定。

2.2.1 规约的作用

促进协作：
- 任务分配：团队可以基于规约并行开发不同的模块，而无需等待其他部分完成。
- 接口定义：规约为不同组件之间的交互提供了清晰的界面，促进了模块化开发。
定义责任：
- 实现者的责任：确保函数在满足前置条件的情况下，始终满足后置条件。
- 使用者的责任：确保在调用函数时满足其前置条件。
隔离变化：
- 实现的自由度：只要不违反规约，实现者可以自由地优化或修改内部逻辑，而无需通知使用者。
- 向后兼容：规约的稳定性允许系统其他部分在不知情的情况下进行更新，这是大型系统演化的关键。

2.3 行为等价性

行为等价性是软件工程中的一个重要概念，它帮助我们判断两个不同的实现是否可以互相替换。这个概念对于代码重构、优化和维护都具有重要意义。

2.3.1 判断行为等价性的原则

用户视角：从调用者的角度看，两个实现是否产生相同的可观察结果。这强调了黑盒测试的重要性。
规约遵守：两个实现是否都满足给定的规约。这包括满足前置条件、后置条件和不变量。
边界条件处理：在各种边界条件和特殊输入下，两个实现是否表现一致。这通常是区分好的实现和优秀实现的关键。

行为等价性的概念挑战了我们对"正确性"的理解。它表明，只要满足规约，就可能存在多个正确的实现，这为优化和改进提供了空间。

2.4 规约的结构：前置条件和后置条件

规约的结构源于霍尔逻辑（Hoare logic），它提供了一种形式化方法来描述和验证计算机程序的正确性。规约通常由两个主要部分组成：前置条件和后置条件。

2.4.1 前置条件（Precondition）

前置条件定义了函数被调用时必须满足的条件。它是对函数输入的约束，也是对调用者的要求。

特点：

限制输入范围：明确函数能够处理的输入类型和值域。
确保函数可以正常执行：为函数的正确执行提供必要的前提。
由调用者负责满足：这是调用者的义务，也是函数实现者可以做出的假设。

2.4.2 后置条件（Postcondition）

后置条件定义了函数执行后必须满足的条件。它描述了函数的预期输出和副作用。

特点：

描述函数的效果：明确函数执行后系统状态的变化。
保证输出的性质：定义返回值的特征和约束。
由函数实现者负责满足：这是实现者的义务，也是调用者可以依赖的保证。

2.4.3 异常处理

当前置条件不满足时，函数的行为被称为异常行为。良好的异常处理机制是健壮软件的关键特征。

异常处理的原则：

快速失败：一旦检测到异常情况，应该立即报告，而不是试图继续执行。
提供有用的错误信息：异常信息应该清晰地指出问题的性质和可能的解决方法。
保持一致性：异常处理不应该让系统处于不一致或未定义的状态。

2.5 规约的验证

验证规约是确保软件质量的关键步骤。它涉及到两个主要方面：静态验证和动态验证。

2.5.1 静态验证

静态验证是在不运行代码的情况下进行的检查。它的优势在于可以在早期发现问题，节省测试和调试的时间。

方法：

代码审查：开发者互相检查代码，确保它符合规约和编码标准。
静态分析工具：自动检查代码是否违反某些规则或模式。
形式化方法：使用数学方法证明代码满足规约，这是最严格但也最复杂的验证方式。

2.5.2 动态验证

动态验证是通过运行代码来检查其行为是否符合规约。它可以捕获静态分析难以发现的问题。

方法：

单元测试：为每个函数编写测试用例，覆盖各种可能的输入。
集成测试：测试多个组件的交互，确保它们能够正确协同工作。
系统测试：测试整个系统的行为是否符合预期。

2.5.3 黑盒测试

黑盒测试是一种特殊的动态验证方法，它只关注函数的输入和输出，不考虑内部实现。这种方法特别适合验证规约的遵守情况。

步骤：

分析规约，确定输入域和输出域。
设计测试用例，包括正常情况、边界值、特殊值和异常情况。
执行测试，比较实际输出与预期输出。

黑盒测试的优势在于它可以独立于实现进行，使得测试可以并行于开发进行，甚至可以在实现完成之前就设计好测试用例。

3. 规约的设计原则

设计好的规约是创建高质量软件的关键。本节将深入探讨规约的分类、设计准则和实际应用中的权衡。

3.1 规约的分类

规约可以从多个维度进行分类，每种分类方式都有助于我们更好地理解和设计规约。

3.1.1 确定性

确定性规约：
- 定义：对于给定的输入，总是产生唯一确定的输出

特点：可预测性高，易于测试和验证
- 应用：大多数数学函数，如绝对值计算

非确定性规约：
- 定义：允许多个可能的输出
- 特点：提供更大的实现灵活性，但增加了测试的复杂性
- 应用：随机数生成、并发系统中的行为

非确定性规约在某些场景下是必要的，例如在模拟真实世界的随机性或处理并发操作时。然而，它们的使用需要格外小心，因为它们可能导致不可重现的错误和难以调试的问题。

3.1.2 抽象程度

抽象规约：
- 定义：只描述"做什么"，不涉及"如何做"
- 特点：提供最大的实现自由度，适合接口定义
- 应用：API设计、面向对象编程中的接口定义
具体规约：
- 定义：包含一些实现细节或限制
- 特点：限制了实现的自由度，但可能提供更好的性能保证
- 应用：性能关键的系统部分，特定算法的实现

抽象规约和具体规约之间的选择常常涉及到灵活性和性能之间的权衡。在大型系统中，通常在系统的高层使用抽象规约，而在底层实现中使用更具体的规约。

3.1.3 强度

强规约：
- 定义：前置条件更宽松，后置条件更严格
- 特点：对调用者要求少，对实现者要求高
- 优点：提供更强的保证，易于使用
- 缺点：实现难度大，可能影响性能
弱规约：
- 定义：前置条件更严格，后置条件更宽松
- 特点：对调用者要求高，对实现者要求低
- 优点：易于实现，可能有更好的性能
- 缺点：使用时需要更多注意，提供的保证较弱

规约强度的选择涉及到调用者和实现者之间责任的平衡。强规约通常更有利于创建可靠的系统，但可能带来性能开销。弱规约则可能带来更好的性能，但使用时需要更多的谨慎。

3.2 设计优质规约的准则

设计好的规约是一门艺术，需要平衡多个因素。以下是一些关键准则：

内聚性：
- 原则：规约应描述单一、明确的功能
- 重要性：提高代码的可理解性和可维护性
- 实现：避免"万能"函数，将复杂功能分解为多个简单函数
信息充分：
- 原则：提供足够的细节，避免歧义
- 重要性：确保调用者和实现者对函数行为有一致的理解
- 实现：明确说明参数的有效范围、返回值的含义、可能的异常情况
鲁棒性：
- 原则：考虑各种边界情况和异常情况
- 重要性：提高系统的可靠性和容错能力
- 实现：明确规定如何处理无效输入、资源不足等异常情况
适度承诺：
- 原则：不要过度承诺难以保证的功能
- 重要性：保持实现的灵活性，避免过度约束
- 实现：使用适当的抽象级别，避免在规约中指定不必要的实现细节
使用抽象数据类型：
- 原则：在规约中使用抽象数据类型而非具体实现
- 重要性：提高代码的灵活性和可扩展性
- 实现：使用接口或抽象类型，而非具体的实现类
一致性：
- 原则：在整个系统中保持规约风格的一致性
- 重要性：提高系统的可理解性和可维护性
- 实现：制定和遵循团队的规约编写指南
可测试性：
- 原则：设计便于测试的规约
- 重要性：简化测试过程，提高代码质量
- 实现：避免依赖难以控制的外部状态，明确规定可观察的行为

3.3 前置条件vs后置条件处理

在设计规约时，一个常见的问题是如何在前置条件和后置条件之间分配责任。这个决策涉及到多个因素：

检查成本：
- 考虑点：检查某个条件的计算成本
- 权衡：如果检查代价高昂，可能更适合作为前置条件
- 例子：复杂的数据结构完整性检查
函数可见性：
- 考虑点：函数的使用范围和频率
- 权衡：
  - 私有函数可以使用更严格的前置条件，因为调用点有限且可控
  - 公共函数应该更宽松，在函数内部进行更多的检查和错误处理
错误处理策略：
- 考虑点：系统的整体错误处理策略
- 权衡：
  - 防御式编程倾向于在函数内部进行更多检查
  - 契约式编程倾向于使用更严格的前置条件
性能考虑：
- 考虑点：检查对性能的影响
- 权衡：在性能关键的部分，可能需要减少运行时检查，增加前置条件
可重用性：
- 考虑点：函数在不同上下文中的可重用性
- 权衡：更宽松的前置条件通常会提高函数的可重用性