何时应该将类拆分为结构和结构生成器类

Question

例如，我们有下一个类。

class Request{
public:
RequestHeader header;
String body;
Request(const RequestHeader& header, const String& body); 
Request(const String& json); 
};

一些文章建议拆分Request实体和Request构建逻辑。例如，接下来。

struct Request{ //RequestDTO?
RequestHeader header;
String body;
};
class RequestBuilder{
public:
static Request build(const RequestHeader& header, const String& body);
static Request build(const String& json);
};

我们应该在什么时候使用此建议？乍一看，它是无用的综合体。构造函数是类的正常部分。我们为什么要避免这种情况？

Answer 1

您显示的分隔看起来很奇怪，因为RequestBuider看起来没有添加任何内容，而且可能会增加所需的认知负荷。

作为一个基于观点的答案，我确实喜欢使用流畅的构建器或命名参数(在支持这一点的语言中(来提高代码的可读性。我的经验法则是使用一个最多有3个参数的构造函数；当我有一个接收4-7个参数的类时，可能会使用一个流利的生成器；当有7个以上的参数时，一定要使用一个。

重要的是要记住，代码应该易于阅读，意图应该(尽可能(简单易懂。这将有助于维护代码，让每个人的生活都变得更好：(。