13.11　总结

我们介绍了很多用于表示配置参数的方法。它们的大多数都基于在第9章“序列化和保存——JSON、YAML、Pickle、CSV和XML”中介绍的序列化技术。configparser模块提供了另外一种格式，为一些用户提供了方便。

对于配置文件来说，关键功能是内容可以被很容易地编辑。基于这个原因，pickle文件并不是推荐的格式。

13.11.1　设计要素和折中方案

配置文件可以简化应用程序的运行和服务器的启动，可以将所有相关参数放在容易读写的文件中。可以将这些文件放在配置的控制范围内，追踪修改历史记录，并使用它们来提高软件质量。

在使用这些文件时，在格式上有一些选择，它们编辑起来都很容易，但在解析的难易程度上以及对Python数据编码的限制上，它们是不同的。

• INI文件：这些文件解析起来很容易并且只限制使用字符串和数字。
  • Python代码（PY文件）：这些文件在配置中使用脚本。不需要解析，类型没有限制。它们使用一个exec()文件，它解析起来很容易并且类型没有限制。
• JSON或YAML文件：这些文件解析起来很容易。它们支持字符串、数字、字典和集合。YAML可以对Python进行编码，但为什么不直接使用Python？
• 特性文件：这些文件需要特殊的解析器。只能使用字符串。
• XML文件：
  • .plist文件：这些文件解析起来很容易。它们支持字符串、数字、字典和集合。
  • 自定义的XML：这些文件需要特殊的解析器。它们只能使用字符串。

在多种应用或服务器共存的环境中，需要选择一个更好的配置文件格式。如果有其他的应用使用了.plist或INI文件，就需要做出选择：哪种格式使用起来更容易。

从对象可以被表示的广度来看，配置文件可以被分为4类。

• 只有字符串的简单文件：自定义XML，特性文件。

• 简单的Python文本的简单文件：INI文件。

• 支持Python文本、集合以及字典的更复杂的文件：JSON、YAML、.plist和XML。

• 一切和Python相关的：可以使用YAML，但当Python具备了更清晰的语法时，不必要再使用YAML。

13.11.2　创建共享配置

在第17章“模块和包的设计”中，会介绍一些有关模块设计需要考虑的点以及什么样的模块适合使用单例设计模式。意味着只需要导入模块一次，实例是共享的。

正是因为这一点，需要将配置定义在一个单独的模块中，然后进行导入。这样就可以在不同的模块间共享一个公共的配置。在每个模块中导入共享的配置模块。配置模块用于查找配置文件然后创建配置对象。

13.11.3　模式演化

配置文件是面向公共API的一部分。在设计应用时，需要解决模式演化的问题。当修改一个类定义时，如何修改配置？

由于配置文件中包含了默认值，它们通常带来了灵活性。从原则上来说，它们完全是可选的。

当软件的主版本更新时——在API或数据库模型发生变化时——配置文件也可能需要做很大的改动。为了区分新旧版本的配置参数，配置文件的版本号也需要改。

当版本发生大改动时，配置文件（例如数据库、输入和输出文件和API）需要考虑兼容性。在处理配置参数的默认值时，需要考虑到主版本的改动。

对应用程序来说，配置文件是第1级输入。没有任何一种可以经过深思熟虑的可替代方案。像其他的输入输出一样，它需要经过仔细的设计。当我们看第14章“Logging和Warning模块”以及第16章“使用命令行”时，会对如何解析配置文件的基础部分进行展开介绍。

13.11.4　展望

在之后的几章中，我们将会介绍有关高扩展性的设计要素。在第14章“Logging和Warning模块”中，将介绍如何使用logging和warnings模块来完成审计信息的创建和调试。在第15章“可测试性的设计”中，会介绍有关可测试性的设计，以及如何使用unittest和doctest。在第16章“使用命令行”中，会介绍如何使用argparse模块来完成选项和参数的解析，进一步使用命令设计模式创建程序组件，这样一来，在无需修改shell脚本的前提下就可以完成组件的扩展性和可结合性。在第 17 章“模块和包的设计”中，将会介绍有关模块和包的设计。在第18章“质量和文档”中，会介绍如何创建设计说明文档，它能够诠释软件功能的正确性和可靠性。