通过继承简化公共头文件的实践是否合理？有无相关命名？

问题背景 #

我正在开发一个解析库，包含供大型软件调用的公共头文件。其中DataObject类作为数据容器，拥有size_t、float、std::string类型的字段。解析器需要的setter要接受std::string参数并尝试转换为对应成员类型，转换失败则返回错误，但这类解析专用的setter不能出现在公共头文件里，公共接口只保留参数类型与成员类型匹配的setter。于是我创建了非公开的子类DataObjectChild，把解析专用setter放在其中，示例代码如下：

DataObject.h（公共头文件） #

class DataObject {
public:
   void setValue1(size_t value) { this->value1 = value; }
   size_t getValue1() { return this->value1; }

   void setValue2(size_t value) { this->value2 = value; }
   size_t getValue2() { return this->value2; }

private:
   size_t value1, value2; 
};

DataObjectChild.h（内部头文件） #

#include <string>
#include "DataObject.h"

struct DataObjectChild : public DataObject {
   void setValue1(std::string value) { 
       // 实际应添加转换异常处理，比如catch std::invalid_argument等
       this->value1 = std::stoi(value); 
   }

   void setValue2(std::string value) { 
       this->value2 = std::stoi(value); 
   }
};

问题解答 #

1. 该实践是否属于常用方案，还是不良实践？ #

这是合理且常用的实践，不属于不良设计。核心优势在于：

• 严格遵循了接口隔离原则：公共接口只暴露外部调用者需要的方法，避免把内部解析的细节（字符串转换逻辑）暴露给上层软件，保持公共API的简洁性和稳定性。
• 隔离内部实现与公共接口：解析逻辑的变动（比如转换规则调整、错误处理优化）不会影响公共头文件，降低了对调用方的耦合。

需要注意几个潜在问题：

• 避免子类添加额外成员变量：如果DataObjectChild新增成员，当把它向上转型为DataObject时会发生对象切片，导致数据丢失。当前示例中仅添加方法，不存在这个问题。
• 完善转换错误处理：示例代码里std::stoi会抛出异常，解析器需要捕获这些异常并返回明确的错误信息，避免程序直接崩溃。

2. 若该实践常用，是否有对应的名称？ #

这个实践属于**接口隔离原则（Interface Segregation Principle, ISP）**的具体应用，而这个子类本身可以被称为：

• 私有扩展子类（Private Extension Subclass）：明确它是仅内部使用的、对公共类的功能扩展。
• 工具子类（Utility Subclass）：强调它是为了完成特定内部任务（解析字符串转换）而创建的辅助类。

另外，这种将公共接口与内部实现逻辑分离的思路，也可以看作是封装内部实现细节的典型做法。

内容的提问来源于stack exchange，提问作者André Lehto