单机版类

Question

在我正在做的一个项目中，我们有几个“一次性”类。我所说的disposable是指它们是一个类，你可以在其中调用一些方法来设置信息，然后调用等同于doit函数的东西。你只需doit一次，就可以把它们扔掉。如果您想再次执行doit，则必须创建该类的另一个实例。它们没有被简化为单个函数的原因是，它们必须存储状态，以便在它们引用之后，用户可以获得发生了什么的信息，并且通过引用参数返回一堆东西似乎不是很干净。doit。它不是一个单例，但也不是一个普通的类。

这是一种糟糕的做事方式吗？对于这类事情，有没有更好的设计模式？或者我应该让步，让用户传入一大堆引用参数来返回一大堆东西？

Answer 1

您描述的是，而不是类(状态+更改它的方法)，而是算法(将输入数据映射到输出数据)：

result_t do_it(parameters_t);

你为什么认为你需要一个这样的类呢？

Answer 2

我用过similar design，对此我也很好奇。一个虚构的简化示例可能如下所示：

FileDownloader downloader(url);
downloader.download();
downloader.result(); // get the path to the downloaded file

为了使其可重用，我将其存储在boost::scoped_ptr中

boost::scoped_ptr<FileDownloader> downloader;

// Download first file
downloader.reset(new FileDownloader(url1));
downloader->download();

// Download second file
downloader.reset(new FileDownloader(url2));
downloader->download();

回答你的问题:我认为这是可以的。我没有发现这个设计有任何问题。

Answer 3

据我所知，您正在描述一个表示算法的类。配置算法，然后运行算法，然后得到算法的结果。如果替代方法是一个接受7个配置参数和5个输出引用的函数，我认为将这些步骤放在一个类中并没有什么错。

这种代码结构还有一个优点，即您可以将算法拆分成几个步骤，并将它们放在单独的私有成员函数中。你也可以在没有类的情况下做到这一点，但如果算法有很多状态，这可能会导致子函数有很多参数。在类中，您可以通过成员变量方便地表示该状态。

您可能需要注意的一件事是，以这种方式构建代码很容易诱使您使用继承在类似的算法之间共享代码。如果算法A定义了算法B所需私有帮助器函数，则很容易使该成员函数受到保护，然后通过让类B从类A派生来访问该帮助器函数。同样，定义包含公共代码的第三个类C，然后让A和B从C派生也很自然。根据经验，仅用于在非虚方法中共享代码的继承并不是最好的方式-它不灵活，最终必须承担超类的数据成员，并且破坏了超类的封装。作为这种情况的经验法则，最好在不使用继承的情况下将公共代码从两个类中分离出来。您可以将该代码分解到一个非成员函数中，也可以将其分解到一个实用程序类中，然后在不从中派生的情况下使用该实用程序类。

YMMV -什么是最好的取决于具体情况。将代码分解到一个公共超类中是template method pattern的基础，因此在使用虚方法时，继承可能是您想要的。