Configuration 使用类层次结构来构造配置设置的不同部分会产生哪些问题？

这是我问题的背景。典型的做法是将配置值组织到不同的文件中。在我的例子中，我的标准是易于编辑和从一台服务器到另一台服务器的可移植性。该软件包用于互联网支付，其设计目的是使软件包的单个安装可用于不同的应用程序。此外，我们希望应用程序在不同的服务器上可以有不同的阶段（开发、测试、暂存和生产）。我为以下三个类别中的每一个使用不同的文件：仅依赖于应用程序的配置值、仅依赖于服务器的配置值以及两者都依赖的配置值。通过这种方式，我可以轻松地将仅依赖于应用程序的配置值从一台服务器移动到另一台服务器，例如从开发移动到生产。它们经常被编辑。所以，这是值得的。类似地，我可以在单个文件中编辑特定于服务器的值，而不必为不同的应用程序维护冗余副本。术语“配置值”包括在不同的应用程序或服务器（甚至功能）中必须以不同方式定义的任何内容。如果函数的定义取决于应用程序或服务器，则它是配置过程的一部分。术语“配置值”对我来说似乎很自然，即使它包含函数

---

现在，问题来了。我希望函数是可测试的。我使用PHP，但也许这个问题在其他语言中也有意义。我决定将配置值作为属性和方法存储在类中，并使用类层次结构来组织不同的类别。基类是

PaymentConfigServer

（仅取决于服务器）。依赖于应用程序的值位于

PaymentConfigApp extends PaymentConfigServer

中，依赖于这两个值的值位于

PaymentConfig extends PaymentConfigApp

中。类

PaymentConfigApp

包含依赖于应用程序或服务器的配置值，但文件本身包含仅依赖于应用程序的值。类似地，

PaymentConfig

包含所有conf值，但文件本身包含的值仅依赖于两者。使用类层次结构会导致问题吗？我不是在寻找关于最佳方法的讨论。我只是想知道，如果你遇到类似的情况，我应该记住什么问题，可能会出现什么冲突，等等

通常，子类用于添加或修改功能，而不是删除功能。因此，您建议的单一继承方法存在一个概念性问题，如果/当您遇到总线时，可能会导致任何必须维护应用程序的人感到困惑：基类提供对特定于服务器的配置的支持，但是您（假装）删除

PaymentConfigApp

子类中的该功能，并（假装）在其

PaymentConfig

子类中重新添加该功能

我不熟悉PHP语言，但如果它支持多重继承，那么我认为有两个基类更符合逻辑：

PaymentConfigServer

和

PaymentConfigApp

，然后从这两个基类继承

PaymentConfig

另一种方法可能是只使用一个类，其中构造函数接受一个枚举参数（或一对布尔参数），该参数用于指定该类是只处理特定于服务器的配置，还是只处理特定于应用程序的配置，还是同时处理这两种类型的配置

---

顺便说一下，您建议的维护配置数据的方法不是我使用过的方法。如果您对阅读替代方法感兴趣，那么您可以阅读有关您的建议的。

，我不需要在运行时只包含应用程序值或服务器值的配置对象。我只需要在源代码中进行分离，目的是便于编辑和移植配置文件。在运行时为这三个类别使用单独的配置对象的想法是完全不同的，我在这里没有提到。也许我应该将这些类抽象化，但最后一个类PaymentConfig除外，它是唯一需要实例化的类。