何时使用对象实例变量与向方法传递参数
您如何决定将参数传递给方法还是简单地将它们声明为对所有对象的方法都可见的对象实例变量？
我更喜欢将实例变量保留在类末尾的列表中，但随着程序的增长，该列表会变得更长。 我认为如果一个变量被传递得足够频繁，它应该对所有需要它的方法都是可见的，但后来我想知道，“如果所有东西都是公共的，那么就根本不需要传递任何东西了！”
How do you decide between passing arguments to a method versus simply declaring them as object instance variables that are visible to all of the object's methods?
I prefer keeping instance variables in a list at the end of the Class, but this list gets longer as my program grows. I figure if a variable is passed often enough it should just be visible to all methods that need it, but then I wonder, "if everything is public there will be no need for passing anything at all!"
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
由于您指的是实例变量，因此我假设您正在使用面向对象的语言。 在某种程度上，何时使用实例变量、如何定义其范围以及何时使用局部变量都是主观的，但是在创建类时可以遵循一些经验规则。
实例变量通常被视为类的属性。将它们视为将从类创建的对象的形容词。 如果您的实例数据可用于帮助描述对象，那么可以肯定它是实例数据的不错选择。
局部变量在方法范围内使用，以帮助它们完成工作。通常，方法的目的应该是获取一些数据、返回一些数据和/或处理/运行一个一些数据的算法。 有时，将局部变量视为帮助方法从头到尾完成的方法会有所帮助。
实例变量作用域不仅是为了安全，也是为了封装。不要假设“目标应该是保持所有变量私有”。 在继承的情况下，将变量设置为受保护通常是一个不错的选择。 您无需将所有实例数据标记为公共，而是为那些需要外部世界访问的实例数据创建 getter/setter。 不要让它们全部可用——只提供您需要的那些。 这将贯穿整个开发生命周期 - 从一开始就很难猜测。
当谈到在类中传递数据时，如果没有看到一些代码，很难说您正在做的事情是好的实践。 有时，直接对实例数据进行操作就可以了； 其他时候则不然。 在我看来，这是随着经验而来的——随着面向对象的思维能力的提高，你会发展出一些直觉。
Since you're referring to instance variables, I'm assuming that you're working in an object-oriented language. To some degree, when to use instance variables, how to define their scope, and when to use local variables is subjective, but there are a couple of rules of thumb you can follow whenever creating your classes.
Instance variables are typically considered to be attributes of a class. Think of these as adjectives of the object that will be created from your class. If your instance data can be used to help describe the object, then it's probably safe to bet it's a good choice for instance data.
Local variables are used within the scope of methods to help them complete their work. Usually, a method should have a purpose of getting some data, returning some data, and/or proccessing/running an algorithm on some data. Sometimes, it helps to think of local variables as ways of helping a method get from beginning to end.
Instance variable scope is not just for security, but for encapsulation, as well. Don't assume that the "goal should be to keep all variables private." In cases of inheritance, making variables as protected is usually a good alternative. Rather than marking all instance data public, you create getters/setters for those that need to be accessed to the outside world. Don't make them all available - only the ones you need. This will come throughout the development lifecycle - it's hard to guess from the get go.
When it comes to passing data around a class, it's difficult to say what you're doing is good practice without seeing some code . Sometimes, operating directly on the instance data is fine; other times, it's not. In my opinion, this is something that comes with experience - you'll develop some intuition as your object-oriented thinking skills improve.
这主要取决于您存储在变量中的数据的生命周期。 如果数据仅在计算期间使用，请将其作为参数传递。
如果数据绑定到对象的生命周期，请使用实例变量。
当变量列表变得太长时，也许最好考虑将类的某些部分重构为新类。
Mainly this depends on the lifetime of the data you store in the variable. If the data is only used during a computation, pass it as a parameter.
If the data is bound to the lifetime of the object use an instance variable.
When your list of variables gets too long, maybe it's a good point to think about refactoring some parts of the class into a new class.
在我看来，只有在跨调用使用数据时才需要实例变量。
下面是一个示例：
现在让我们想象一下 myDrawing 类使用 15 个辅助函数来创建 myCircle 对象，每个函数都需要中心和半径。 它们仍然不应该被设置为 myDrawing 类的实例变量。 因为他们永远不会再被需要。
另一方面，myCircle 类需要将圆心和半径存储为实例变量。
为了让 myCircle 对象在进行这些新调用时知道它的半径和中心是什么，需要将它们存储为实例变量，而不仅仅是传递给需要它们的函数。
所以基本上，实例变量是保存对象“状态”的一种方法。 如果变量不需要知道对象的状态，那么它不应该是实例变量。
至于公开一切。 它可能会让你此刻的生活更轻松。 但它会回来困扰你。 皮斯不。
In my opinion, instance variables are only necessary when the data will be used across calls.
Here's an example:
Now lets imaging the myDrawing class uses 15 helper functions to create the myCircle object and each of those functions will need the center and the radius. They should still not be set as instance variables of the myDrawing class. Because they will never be needed again.
On the other hand, the myCircle class will need to store both the center and radius as instance variables.
In order for the myCircle object to know what it's radius and center are when these new calls are made, they need to be stored as instance variables, not just passed to the functions that need them.
So basically, instance variables are a way to save the "state" of an object. If a variable is not necessary to know the state of an object, then it shouldn't be an instance variable.
And as for making everything public. It might make your life easier in the moment. But it will come back to haunt you. Pease don't.
恕我直言：
如果变量构成实例状态的一部分，那么它应该是一个实例变量 - 类实例有一个实例变量。
如果我发现自己重复地将某些内容传递到实例的方法中，或者我发现我有大量实例变量，我可能会尝试查看我的设计，以防我错过了某些内容或在某处进行了错误的抽象。
希望能帮助到你
IMHO:
If the variable forms part of the state of the instance, then it should be an instance variable - classinstance HAS-A instancevariable.
If I found myself passing something repeatedly into an instance's methods, or I found that I had a large number of instance variables I'd probably try and look at my design in case I'd missed something or made a bad abstraction somewhere.
Hope it helps
当然，在类中保留一大堆公共变量是很容易的。 但即使凭直觉，您也可以看出这不是正确的方法。
在使用每个变量之前定义它。 如果变量支持特定方法的功能，则仅在该方法的范围内使用它。
还要考虑安全性，公共类变量很容易受到“外部”代码的不需要的更改。 您的主要目标应该是将所有变量保持私有，并且任何不是私有的变量都应该有充分的理由这样做。
关于将参数一直传递到堆栈，这很快就会变得丑陋。 经验法则是保持方法签名干净和优雅。 如果您看到许多方法使用相同的数据，请确定它是否足够重要以成为类成员，如果不是，请重构您的代码以使其更有意义。
这归结为常识。 准确思考在何处以及为何声明每个新变量，它的功能应该是什么，然后决定它应该存在于哪个作用域中。
Of course it is easy to keep one big list of public variables in the class. But even intuitively, you can tell that this is not the way to go.
Define each variable right before you are going to use it. If a variable supports the function of a specific method, use it only in the scope of the method.
Also think about security, a public class variable is susceptible to unwanted changes from "outside" code. Your main goal should be to keep all variables private, and any variable which is not, should have a very good reason to be so.
About passing parameters all they way up the stack, this can get ugly very fast. A rule of thumb is to keep your method signatures clean and elegant. If you see many methods using the same data, decide either if it's important enough to be a class member, and if it's not, refactor your code to have it make more sense.
It boils down to common sense. Think exactly where and why you are declaring each new variable, what it's function should be, and from there make a decision regarding which scope it should live in.