在运行时反复使用和对象的最佳实践是什么答案

【问题标题】：What is best practice for using and object over and over in runtime在运行时反复使用和对象的最佳实践是什么
【发布时间】：2013-03-20 08:22:46
【问题描述】：

我有一个班级，名为 Contoller。我想从该类创建一个对象，并在运行时一遍又一遍地更改 transactionValue 和 transactionId。什么是最好的方法。我想我可以从默认构造函数创建一个对象并将 setControllerValues 用于新值。这是最佳做法吗？

class Controller{
public:
    Controller();
    Controller(int,int);
    setControllerValues(int,int);
private:
    int transactionValue;
    int transactionId;
};


int main()
{
    Controller ct;
    ct.setControllerValues(3,4);
    ct.setControllerValues(6,7);
    ct.setControllerValues(34,45);
}

编辑：我听说过一些关于单例的事情。我应该用它吗？（我改变了“骨架”）

【问题讨论】：

是的，这似乎很有效。
除了可能为方法使用更好的名称，甚至为每个值使用单独的方法之外，我想不出其他任何东西。

标签： c++ class object static singleton

【解决方案1】：

让它成为全球性的！不，等等，全局变量很糟糕。让它成为单例！不，等等，单例是一种反模式。将它作为参数传递到任何需要的地方！不，等等，tramp 数据很糟糕。让它成为全球性的！

一个人要做什么？

您支付您的钱，然后您做出选择。

【讨论】：

【解决方案2】：

是的，这可以被认为是一种很好的做法。那里没有什么问题。也许您想在写信给setControllerValues 中的私人成员之前进行一些数据验证。但是其中的一部分是非常简单的 OOP。

【讨论】：

事实上，通过创建对象来避免性能下降是一种常见的模式
@ckruse，它有一个名字：过早优化，通常是错误的做法。
@ZdeslavVojkovic 我认为您并没有真正理解“过早优化”和“高效编码”之间的区别。
ckruse，是的，我做到了。在应用程序的整个生命周期中节省一些指令，同时引入更多错误的可能性并使设计不那么灵活，这不是有效的编码。我已经列举了缺点，只有一个优点：少几个周期。正如我所说，这是一个糟糕的权衡
@Jueecy，是我。我在回答中解释了原因以及为什么我认为这通常不是好的做法。如果它说有时这是一种很好的做法（它可以是），我不会投反对票。 IMO，对于给定的示例，这是一个糟糕的选择，但这并不意味着它总是一个糟糕的选择。

【解决方案3】：

视情况而定。

如果没有可变状态（或很少），一些程序更容易推理；例如，多线程程序。

其他面向对象的方法会说 getter 和 setter 是可恶的。

在性能和在堆栈上创建新对象方面，c++11 和编译器非常擅长找出创建高效机器代码的最佳方法，远胜于你我。

我会考虑使用赋值运算符。它允许您使用来自一个对象的值来修改另一个对象：

class Controller {
public:
    Controller& operator=(const Controller& other) {
        transactionValue = other.transactionValue;
        transactionId = other.transactionId;
        return *this;
    }        
private:
    int transactionValue;
    int transactionId;
};

并使用：

Controller permanent(12, 5678);
//...
permanent = Controller(23, 6789);

【讨论】：

【解决方案4】：

你听到的可能是singleton，而不是骷髅。

当然，您可以使用您展示的方法，但让我问您：您为什么选择这种方法而不是创建单独的对象？

我不喜欢它，原因如下：

如果您真的想确保整个应用程序中的单个实例，您需要一个合适的单例（不是我喜欢它）。您当前的实现不会阻止任何人创建另一个控制器
处理多个实例比对单个实例的共享访问要容易得多。如果您必须将此对象提供给其他函数，甚至更糟的是线程，该怎么办？
不可变对象比可变对象更容易推理。可变状态是导致大量错误的原因，因为它提供了更多使类型不变量无效的机会
实际上，除了调用构造函数的成本之外，您一无所获，与您需要执行的其他逻辑相比，它的成本更低

简而言之，我认为这种方法没有任何好处，因为我不知道其他可能使其更合理的要求。您已经引入了很多额外的复杂性来在对象创建期间保存一些指令，无论如何编译器都会对其进行优化。这是一个糟糕的权衡，IMO。

关于单身人士，总的来说我也不喜欢他们 :) 原因如下：

我非常怀疑类本身是否知道其生命周期问题（单例、瞬态、每个线程等）。这是客户通常更了解的事情
测试依赖单例的代码要困难得多
共享状态 + 多线程 = 使用调试器的夜晚

话虽如此，有时它们是完全合理的。但是，您的示例似乎并非如此。

【讨论】：