c++ - C++ 构造函数重载的经验法则？

Question

在 C++ 中，我经常(几乎总是)遇到构造函数问题；我永远不确定如何使用这些参数，最终我最终会为每个类只使用无参数构造函数。然后我将在每个实例定义之后使用 setter。例如:

// Obviously better
Point p(5, 3);

// ...and yet I end up using this
Point p;
p.setX(5);
p.setY(3);

我最终使用“更差”方法的原因是因为有些类有太多的参数并且有太多不同的可能性来构建它们，所以我的思绪变得困惑，我不再知道我应该做什么。这是我最近制作的类(class)示例(它使用 Qt):

// implements position and pixmap (image shown when painted)
class Block : QObject {
    public:
        Block(const QPixmap &img = Pixmap(), QObject *parent = 0);
        Block(const QPoint &pos, const QPixmap &img = Pixmap(), QObject *parent = 0);
        Block(int x, int y, const QPixmap &img = Pixmap(), QObject *parent = 0);
        Block(const Block &other);
};

只有一个类只有两个属性(position 和 image)，我已经得到四个最多带四个参数的构造函数。此外，我经常看到人们将第一个构造函数替换为 Block(QObject *parent = 0); 和 Block(const QPixmap &img, QObject *parent = 0); 和我我不确定这是否是一件好事。

那么，如果我创建一个我自己的 Rectangle 类，它继承自 Block，那么它还需要采用 image 和position 作为参数:

Rect(const QPixmap &img = QPixmap(), QObject *parent = 0);
Rect(const QRect &rect, const QPixmap &pixmap = QPixmap(), QObject *parent = 0);
Rect(const QSize &size, const QPoint &pos = QPoint(), const QPixmap &img = QPixmap(), QObject *parent = 0);
Rect(const QPoint &pos, const QPixmap &img = QPixmap(), QObject *parent = 0);
Rect(int x, int y, int w = 1, int h = 1, QPixmap &img = QPixmap(), QObject *parent = 0); 
Rect(int w, int h, QPixmap &img = QPixmap(), QObject *parent = 0); 
Rect(const QPoint &pos, int w, int h, QPixmap &img = QPixmap(), QObject *parent = 0);
Rect(int x, int y, const QSize &size, QPixmap &img = QPixmap(), QObject *parent = 0);
Rect(const Rect &rect);

如您所见，它开始看起来很糟糕，而且很难维护。想象一下 Player 类继承自 Rect 并实现了 items、health、mana， 伤害，护甲...我发现不可能编写这样的构造函数。

既然我已经给了你这个问题，我不确定这个问题；我需要任何提示或技巧来帮助我处理构造函数、何时使用默认参数以及我需要多久使用一次所有构造函数，是的，只是一些防止我为一个类创建 500 个构造函数的提示；我应该只使用我原来的 p.setX(5); 示例吗？

Answer 1

如果您正在创建自己的类，您绝对应该避免这种构造函数组合的指数级爆炸式增长。一种方法是提供其他机制来创建类的实例。一般有几种Creational Patterns可以满足各种特定需求的目的。设计模式本身就是一个很大的话题，所以我建议您找一些阅读 Material 来帮助您。

此外，您可能应该重新审视您的设计。通常，当一个构造函数有很多参数或多个具有多种参数的构造函数时，这表明该类负责太多不同的事情。尝试将类重构为更小、更易于管理的 block ，每个 block 负责一个任务。 (参见 Single Responsibility Principle。)