软件设计启发法之——识别可能发生变化的领域

最新推荐文章于 2024-10-16 21:00:08 发布

嘿，小邹同学

最新推荐文章于 2024-10-16 21:00:08 发布

阅读量339

点赞数

分类专栏：软件开发与架构文章标签：软件构建

本文链接：https://blog.csdn.net/weixin_43274002/article/details/124654142

版权

软件开发与架构专栏收录该内容

4 篇文章 0 订阅

订阅专栏

前言

一个对优秀设计者的研究显示，他们共有的一个属性是：预期变化的能力。

适应变化是良好程序设计最具挑战性的方面之一。它的目标是隔离可能产生变化的地方，以便将修改的影响限制在系统中的一个例程、类或包中。

为识别变化做准备的步骤列表

以下是一些可以为识别变化做准备的步骤列表。

确定看起来可能会改变的项目。（Identify items that seem likely to change. ）

如果需求做得很好，包含了潜在的变化的列表以及每次变化的可能性，在这种情况下，识别起来是很容易的。但如果需求没有覆盖可能产生的变化，那么就需要考虑在任何项目中都有可能产生变化的领域。

这需要经验，参考以下列出的常见的容易发生变化的领域列表。
将可能产生变化的项目分开。（Separate items that are likely to change. ）

将在步骤1中发现的可能产生变化的组件划分到单独的一个类，或者划分到与其他可能同时发生变化的组件所在的类中。
隔离看起来可能会改变的项目。（ Isolate items that seem likely to change.）

将类之间的接口设计为对潜在变化不敏感。设计成接口以便将变化只限于类的内部，外部不受影响。

任何其他类使用可能产生变化的类时，都应该不知道发生了变化。类接口应该隐藏自己的信息。（参考：软件开发中的信息隐藏（todo））。

常见的容易发生变化的领域列表

以下是一些可能会产生改变的领域列表。

业务规则（Business rules）

业务规则往往是软件频繁更改的根源。比如保险公司更改费率表、工会重新谈判合同等等。

如果遵循了信息隐藏的原则（参考：软件开发中的信息隐藏（todo）），那么基于这些规则的逻辑不会散布在整个系统中，逻辑只会继续被隐藏在系统中的某个角落直到需要被改变。

硬件依赖（Hardware dependencies）

硬件依赖的例子包括对屏幕、打印机、键盘、鼠标、磁盘驱动器、音响设备和通信设备的接口。

把硬件依赖隔离到它们自己的子系统或类中。这样做有助于在将系统转移到新的硬件环境的时候。

输入和输出（Input and output ）

在比底层硬件接口稍高的设计水平上，输入/输出是一个可能产生变化的领域。

如果应用程序创建了自己本身的数据文件，当系统变得更复杂时，文件格式可能产生变化。用户级的输入和输出也会产生变化——字段在页面上的位置、每页字段的数量、字段的顺序等等。

一般来说，检查所有外部接口是否有可能的更改是一个好主意。

非标准的语言实现。（Nonstandard language features ）

大多数语言实现都包含方便的、非标准化的拓展。使用拓展是一把双刃剑，因为他们可能在不同的环境中可能不能获取，无论这个不同的环境是不同的硬件、不同供应商的语言实现，还是来自相同供应商的一个新的语言版本。

如果使用了编程语言中非标准化的拓展，把这些拓展隐藏在它们自己的类中，以便于当更换不同环境的时候可以用自己的代码替换它们。同样，如果使用了并非在所有环境中都可用的标准库例程（library routines），请将实际的标准库例程隐藏在在另一个环境中也能正常工作的接口后面。（注：这个地方也是面向接口编程的一个思想体现。）

困难的设计和构造区域。（Difficult design and construction areas）

隐藏困难的设计和构建区域是一个好主意（注：这里是信息隐藏的思想体现），因为它们可能做得不好，很可能需要再重新做一次。

将它们区分开来，并尽量减少它们糟糕的设计或构造可能对系统的其余部分产生的影响。

状态变量（Status variables）

状态变量表明了程序的状态，往往比其他大多数数据更频繁的被改变。

在一个典型的编程场景中，最初你可能把错误状态变量定义成一个boolean类型变量，之后你可能觉得使用enum枚举类型更好，这个时候变化就发生了。

可以为状态变量的使用添加至少两个级别的灵活性和可读性：

不要将布尔变量用作状态变量，改用枚举类型。向状态变量添加新状态是很常见的，往枚举类型状态变量中添加一个新的状态只需要重新编译，而不是对每一行使用了布尔变量的代码做修改。
使用一个方法访问变量而不是直接检查变量。通过方法访问变量而不是直接访问，可以进行更复杂的状态变量检查。如果你想修改检查的逻辑，如果该逻辑被隐藏在方法中，那么修改起来会很容易；但如果该逻辑被硬编码成遍布在整个系统，那么修改起来将会很难。