Question

我注意到，即使尊重OOD的单一责任原则，有时课程仍然会变得很大。有时直接在方法中访问成员变量感觉就像拥有全局状态一样，当前范围中存在很多东西。仅通过查看当前工作的方法，就不可能确定当前范围中可访问的invidiual变量的来源。

最近和朋友一起工作时，我意识到我编写了比他更详细的代码，因为我将成员变量作为参数传递给每个方法。

这是不好的做法吗？

编辑：示例：

class AddNumbers {
public:
    int a, b;
    // ...
    int addNumbers {
        // I could have called this without arguments like this:
        // return internalAlgorithmAddNumbers();
        // because the data needed to compute the result is in members.
        return internalAlgorithmAddNumbers(a,b);
    }

private:
    int internalAlgorithmAddNumbers(int sum1, int sum2) { return sum1+sum2; }
};

Answer 1

如果一个类有成员变量，请使用它们。如果要显式传递参数，请将其设为自由函数。传递成员变量不仅会使代码更加冗长，而且还会违反人们的期望并使代码难以理解。

类的整个目的是创建一组具有隐式传递的共享状态的函数。如果这不是您想要做的，请不要使用类。

Answer 2

是的，定义是一种不好的做法。从我的角度来看，将成员变量传递给成员函数毫无意义。它有几个缺点：

降低代码可读性
将参数复制到堆栈上的性能成本

最终将方法转换为简单函数可能有意义。实际上，从性能的角度来看，调用非成员函数实际上更快（不需要取消引用此指针）。

编辑：

回答你的评论。如果函数只能使用明确传递的几个参数来执行其工作，并且不需要任何内部状态，那么可能没有理由声明它具有成员函数。使用简单的C风格函数调用并将参数传递给它。

Answer 3

我理解这个问题，不得不在我最初没作过的代码中维护大类。在C ++中，我们使用关键字const来帮助识别不改变状态的方法：

void methodA() const;

使用它有助于维护，因为我们可以看到方法是否可以改变对象的状态。

在其他没有这个概念的语言中，我更清楚我是否通过引用传入或返回更改来改变实例变量的状态

this->mMemberVariable = this->someMethod();

而不是

void someMethod()
{
   this->mMemberVariable = 1; // change object state but do so in non transparent way
}

多年来我发现这样可以更容易维护代码。

直接访问成员变量或作为参数传递？

3 个答案: