参数与成员变量

发布于 2024-07-13 13:37:42 字数 1578 浏览 4 评论 0原文

我最近一直在使用别人的代码,我意识到这个人对于私有变量和方法参数的理念与我截然不同。 我通常认为私有变量只应该在以下情况下使用:

  1. 需要存储变量以供以后调用。
  2. 存储在变量中的数据在类中全局使用。
  3. 当需要全局操作变量时(这与需要通过每个类方法读取变量截然不同)。
  4. 当它将使编程变得更加容易时。 (诚​​然含糊不清,但在很多情况下,人们必须避免将自己陷入困境)。

(我承认,上面的许多内容都略有重复,但它们似乎都不同,足以值得这样对待......)

这似乎是防止意外更改变量的最有效方法。 遵循这些标准似乎还允许最终操作外部引用(如果该类最终被修改),从而为您在未来留下更多选择。 这只是一个风格问题(就像一个真正的括号或匈牙利命名约定),还是我的这种信念有道理? 在这种情况下实际上有最佳实践吗?

编辑
我认为这需要纠正。 我在上面使用了“全局”,我实际上的意思是“通过实例方法全局”,而不是“任何地方、任何地方都可以全局访问”。

编辑2
有人要求一个例子:

class foo
{
    private $_my_private_variable;

    public function __constructor__()
    {
    }

    public function useFoo( $variable )
    {
        // This is the line I am wondering about,
        // there does not seem to be a need for storing it.
        $this->_my_private_variable = $variable; 
        $this->_doSometing();
    }

    private function _doSomething()
    {

        /*
          do something with $this->_my_private_variable.
        */
        // This is the only place _my_private_variable is used.
        echo $this->_my_private_variable;
    }
}

这就是我会这样做的方式:

class foo
{

    public function __constructor__()
    {
    }

    public function useFoo( $variable )
    {
        $this->_doSometing( $variable );
    }

    private function _doSomething( $passed_variable )
    {
        /*
          do something with the parameter.
        */
        echo $passed_variable;
    }
}

I've recently been working with someone else's code and I realized that this individual has a very different philosophy regarding private variables and method parameters than I do. I generally feel that private variables should only be used in a case when:

  1. The variable needs to be stored for recall later.
  2. The data stored in the variable is used globally in the class.
  3. When the variable needs to be globally manipulated (something decidedly different from the need to read the variable by every class method).
  4. When it will make programming substantially easier. (Admittedly vague, but one has to be in many circumstances to avoid painting oneself into a corner).

(I admit, that many of the above are slightly repetitive, but they each seem different enough to merit such treatment... )

It just seems that this is the most efficient means of preventing changing a variable by accident. It also seems like following these standards will allow for the eventual manipulation of external references (if the class is eventually modified), thus leaving you with further options in the future. Is this simply a style issue (like one true bracket or Hungarian naming conventions), or do I have justification in this belief? Is there actually a best practice in this case?

edit
I think this needs to be corrected. I used "globally" above where I actually meant, "globally by instance methods" not "globally accessible by anything, anywhere".

edit2
An example was asked for:

class foo
{
    private $_my_private_variable;

    public function __constructor__()
    {
    }

    public function useFoo( $variable )
    {
        // This is the line I am wondering about,
        // there does not seem to be a need for storing it.
        $this->_my_private_variable = $variable; 
        $this->_doSometing();
    }

    private function _doSomething()
    {

        /*
          do something with $this->_my_private_variable.
        */
        // This is the only place _my_private_variable is used.
        echo $this->_my_private_variable;
    }
}

This is the way I would have done it:

class foo
{

    public function __constructor__()
    {
    }

    public function useFoo( $variable )
    {
        $this->_doSometing( $variable );
    }

    private function _doSomething( $passed_variable )
    {
        /*
          do something with the parameter.
        */
        echo $passed_variable;
    }
}

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(9

爱的十字路口 2024-07-20 13:37:43

正如其他人所述,由于对象属性旨在保存状态,因此我的策略是默认将所有属性设为私有,除非我有充分的理由公开它们。

如果必须的话,稍后将它们公开要容易得多,例如,只需编写一个 getter 方法(我也不必在编写类时就考虑到这一点)。 但稍后收回公共财产可能需要重写大量代码。

我喜欢保持灵活性,同时不必考虑太多不必要的事情。

Since object properties are meant to hold state, as stated by the others, my policy is to have all of them private by default unless I have a good reason to expose them.

It's much easier to make them public later on, if you have to, simply by writing a getter method for example (which i also don't have to think about right at the beginning of writing a class). But reeling in a public property later on may require a huge amount of code to be re-written.

I like to keep it flexible while not having to think about this more than needed.

允世 2024-07-20 13:37:42

一般来说,类成员应该代表类对象的状态

它们不是方法参数的临时位置(这就是方法参数的用途)。

In general, class members should represent state of the class object.

They are not temporary locations for method parameters (that's what method parameters are for).

停滞 2024-07-20 13:37:42

我声称这不是风格问题,而是可读性/可维护性问题。 一个变量应该有一种用途,并且只能有一种用途。 仅仅因为变量碰巧需要相同的类型而“回收”用于不同目的的变量是没有任何意义的。

从您的描述来看,您所处理的其他人的代码似乎正是这样做的,因为所有其他用途基本上都包含在您的列表中。 简而言之,它根据情况使用私有成员变量作为临时变量。 我的假设正确吗? 如果是这样,那么代码就太糟糕了。

任何给定变量的词法范围和生命周期越小,错误使用的可能性就越小,资源处置也越好。

I claim that it isn't a style issue but rather a readability/maintainability issue. One variable should have one use, and one use only. “Recycling” variables for different purposes just because they happen to require the same type doesn't make any sense.

From your description it sounds as if the other person's code you worked on does exactly this, since all other uses are basically covered by your list. Put simply, it uses private member variables to act as temporaries depending on situation. Am I right to assume this? If so, the code is horrible.

The smaller the lexical scope and lifetime of any given variable, the less possiblity of erroneous use and the better for resource disposal.

素手挽清风 2024-07-20 13:37:42

拥有成员变量意味着它将保持需要在方法调用之间保持的状态。 如果该值不需要在调用之间存在,则它没有理由存在于单个调用的范围之外,因此(如果它存在的话)应该是方法本身内的变量。

风格总是很难的,一旦你形成了一种风格,你可能会陷入一点墨守成规,并且很难看出为什么你所做的可能不是最好的方式。

Having a member variable implies that it will be holding state that needs to be held between method calls. If the value doesn't need to live between calls it has no reason to exist outside of the scope of a single call, and thus (if it exists at all) should be a variable within the method itself.

Style is always a hard one, once you develop one you can get stuck in a bit of a rut and it can be difficult to see why what you do may not be the best way.

掩饰不了的爱 2024-07-20 13:37:42

您应该只在需要的时间和地点创建变量,并在完成后处理它们。 如果类不需要类级变量来运行,那么它就不需要。 在不需要的地方创建变量是非常糟糕的做法。

You should only create variables when and where they are needed, and dispose of them when you are done. If the class doesn't need a class level variable to function, then it just doesn't need one. Creating variables where you don't need them is very bad practice.

垂暮老矣 2024-07-20 13:37:42

类成员应该是以下任意一种:

  • 类的依赖项
  • 表示类状态的变量 类
  • 的方法

Class members should be any of the following:

  • A dependency of a class
  • A variable that represents the state of the class
  • A method of the class
枯寂 2024-07-20 13:37:42

如果您熟悉 C++ 析构函数,我认为答案很简单。 所有成员变量都应该被分配一种被破坏的方式,而函数参数则不然。 这就是为什么成员变量通常是对象的状态或依赖关系,并且它们的生命周期具有某种关系。

I think the answer is straightforward if you are familiar with C++ destructors. All member variables should be assigned a way to be destructed while function parameters are not. So that's why member variables are usually the states or dependicies of an object having some kind of relation regarding their lifecycle.

桜花祭 2024-07-20 13:37:42

我不确定使用全局范围变量与始终作为方法参数传递是否有明确的最佳实践。 (通过“私有变量”,我假设您指的是全局范围的变量。)

使用全局范围的变量是在 .NET 中实现属性的唯一方法(即使自动属性最终也使用全局范围的变量,只是您不必这样做声明自己)。

对于始终使用方法参数存在争议,因为它可以完全清楚值的来源。 我认为这并不能真正帮助阻止该方法对底层值进行更改,而且在我看来,它有时会使内容变得更难以阅读。

I'm not sure there is a stated best-practice for using globally scoped variables versus always passing as method parameters. (By "private variables", I'm assuming you mean globally scoped variables.)

Using a globally scoped variable is the only way to implement properties in .NET (even automatic properties ultimately use a globally scoped variable, just not one you have to declare yourself).

There is a line of arguement for always using method parameters because it makes it completely clear where the value is coming from. I don't think it really helps prevent the method from making changes to the underlying value and it can, in my opinion, make things more difficult to read at times.

—━☆沉默づ 2024-07-20 13:37:42

我不同意为了全球访问或使编程更容易而实施它。 通过在全球范围内公开这些内容而不进行任何类型的过滤,使得将来确定访问变得更加困难。

I would disagree with implementing it for global access or to make programming easier. By exposing these globally without filtering of any kind make it more difficult to determine access in the future.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文