我对在 2 个不同的环境中使用 2 个不同的类感兴趣。两个类应该共享相同的结构(方法),但在生产中使用的会是“轻量级的”,具有较少的验证或较少的功能或不同的操作。
示例:一个不检查字段类型/存在的 SQL 查询类。其他示例:记录但不显示消息的错误处理类。
我认为已经存在一种特定的设计模式,但我真的不知道应该深入研究哪一种。
我对在 2 个不同的环境中使用 2 个不同的类感兴趣。两个类应该共享相同的结构(方法),但在生产中使用的会是“轻量级的”,具有较少的验证或较少的功能或不同的操作。
示例:一个不检查字段类型/存在的 SQL 查询类。其他示例:记录但不显示消息的错误处理类。
我认为已经存在一种特定的设计模式,但我真的不知道应该深入研究哪一种。
这可能只是我......但这是一个非常糟糕的主意。
您不应该在未在开发/测试中运行的实时运行代码。否则,无法验证代码是否正常工作(当然,除了将其推入生产环境并用手指交叉)。
出于这个原因,我认为你不会找到一个很好的例子来说明你正在寻找的东西。
更新
您所描述的内容与原始问题的阅读方式略有不同。如果是这种情况,您可以让您的“框架”读取指定验证和日志记录级别的配置文件。这样,您的配置文件可能会因环境而异,但仍运行相同的代码库。
在不同的环境中使用不同的代码并不是一个好主意。
对于您的场景,我认为最好的选择是将您希望在特定环境中避免的事情外部化为配置方面,并且在部署应用程序时设置详细的日志开/关、字段的完整性检查开/关等。
必须以一致的方式对环境进行任何更改以避免出现问题。版本控制系统和一致的构建和部署过程是您的朋友。
就我而言,我有一个带有沙盒和实时环境的支付网关。我所做的是使用工厂模式+接口(因此所有网关都具有相同的签名)+配置(系统知道需要实例化的类)