应该如何处理可能未使用的类成员以优化性能,未初始化或初始化为某个默认值?

时间:2017-05-16 03:53:21

标签: java c++ oop

假设我有一个班级Test

class Test{
        string testNum, description;
    public:
        Test(string num); // A constructor that only sets testNum = num
};

Test是一个存储我管理的测试的类。 testNum是测试的编号,description是描述测试的可选字符串。

由于description是可选的,有时我会将其包含在Test个对象中,有时我不会。

在上面显示的构造函数中,描述没有传递给构造函数,是不是更好的做法是将description保持未初始化或将其初始化为构造函数中的某个默认值(例如“NO DESCRIPTION”)?

更重要的是,如果将description初始化为默认值,会影响程序性能(例如通过占用不必要的内存或增加运行时间),还是效果可以忽略不计? < / p>

我正在使用C ++(如果这会影响潜在的答案),但一般来说,这可以通过OOP来解答。

1 个答案:

答案 0 :(得分:1)

最佳实践

我认为一般的OOP智慧会说:

  • 尽可能避免使用可选字段,因为它们可能表示对象模型存在缺陷。
  • 当存在可选字段时,更喜欢将它们初始化为默认值,而不是将它们保持为未初始化 - 在调试过程中不必担心这一点。

在类似description之类的情况下,我的初步回答是你可能会让它成为必需的 - 它听起来像一个只是可选的字段,因为你不想强迫某人永远当他们正在考虑其他事情的时候想出一个描述,即使从长远来看如果一切都有描述可能会让生活更轻松。

绩效影响

description之类的值初始化为默认值会带来一些小成本 - 确切的成本取决于它所设置的值以及目标平台的各个方面。在大多数情况下,成本可能可以忽略不计;判断成本是否有意义的最佳方法是使用分析器或类似工具来分析程序花费大部分时间的位置。 As Donald Knuth wrote

  

程序员浪费了大量时间来考虑或担心程序中非关键部分的速度,而这些效率尝试实际上在考虑调试和维护时会产生很大的负面影响。我们应该忘记小的效率,大约97%的时间说:过早的优化是所有邪恶的根源。然而,我们不应该把这个关键的3%的机会放弃。