正确使用 - 访问器/获取器与普通方法
我无法区分代表对象属性和普通方法的访问器/获取器。在 C++ 中，访问器和普通方法的命名约定不同（例如，Google 风格指南建议访问器使用小写字母，普通方法使用 PascalCase）。此外，普通方法和访问器/获取器的顺序（之前或之后）也遵循约定。在 Java 中，人们可能会陷入困境，方法是否应该以“get”或“compute”/“find”开头来分别表示 getter 和普通方法。在 C# 中，存在一个难题：什么应该是属性，什么应该是方法。每当我创建一个新类时，我不知道如何将方法分类为普通方法和 getter。
有没有一种简单的方法来确定什么是对象/访问器/getter 的属性以及什么应该是普通方法？
以下是否与区分访问器/获取器和普通方法有关：
- 计算成本低
- 返回新对象（或副本），而不是 (const) 引用
- 没有 setter
- 有一种方法但间接地影响该“属性”
为了说明这一点，这里是一个例子（C++）：假设我想创建一个可以容纳固定数量元素的数据结构，除了插入/删除操作之外，它还提供了一系列有效的方法包含的元素（即平均值、中值、最小值、最大值等）。现在，以计算平均值的函数为例；有人可能会说这是一个对象的属性，并在插入/删除元素时重新计算它，从而将其视为像 const double& 一样的 getter。平均值（）。另一种方法是按需计算并将其视为普通方法，即 double ComputeAverage()。另外，假设有一个方法返回一组包含的元素；它可以被视为 getter const set 如果不需要每次都计算它，但如果类每次都计算它，则 set 会更合适。
I am having trouble differentiating between accessors/getters, which represent object's properties and normal methods. In C++, the naming conventions for accessors and normal methods are different (e.g. Google Style guide suggests lower-case for accessors and PascalCase for normal methods). Moreover, the order of normal methods and accessors/getters (before or after) is also subject to conventions. In Java, one might have a dilemma whether a method should begin with "get" or "compute"/"find" to indicate a getter and a normal method, respectively. In C#, there is a dilemma what should be a property and what should be a method. Whenever I create a new class, I am not sure how to classify methods to normal methods and getters.
Is there an easy way to determine whether what is a property of an object / accessor/getter and what should be a normal method?
And does any of the following have something to do with differentiating between an accessor/getter and a normal method:
- Computation is cheap
- A new object (or a copy) is returned, instead of (const) reference
- There is no setter
- There is a way to influence that "property" but indirectly
To illustrate this, here is the example (in C++): Suppose I want to create a data structure which can hold a fixed number of elements, and apart from insertion/removal operations it offers a series of methods which work on the elements contained (i.e. average, median, minimum, maximum etc.). Now, take a function which computes the average for example; one might say that this is a property of an object and re-calculate it whenever an element is inserted/removed and thus treat it as a getter like const double& average(). The other way would be to compute it on-demand and treat it as a normal method, i.e. double ComputeAverage(). Also, suppose there is a method which returns a set of contained elements; it could be treated as a getter const set<int>& unique_elements() if there is no need to compute it every time, but if the class computes it every time then the set<int> ComputeUniqueElements() would be more appropriate.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在访问器和“普通方法”之间创建分离是一个坏主意。方法就是方法；它是一个具有某些特定作用的成员函数。成员函数只是设置成员变量的值或返回成员变量的值，这一事实是一个实现细节。
一个好的 API 将外部世界与实现细节隔离开来。外界不应该知道也不关心特定函数只是一个访问器，如果没有其他原因，除了它可以改变这一事实。
假设您的类中有一个
name“属性”。最初，您将其存储为std::string。您提供获取和修改名称的函数。一切都很好。现在，假设您决定更改名称的存储方式。您需要将名称解析为名字和姓氏。外界需要知道你在这样做吗？ setter 方法的名称不需要更改。它的界面不需要改变。需要改变的只是您实现该功能的方式。
Google 的风格指南并不代表 C++ 或其程序员；它只代表谷歌所做的事情。
Creating a separation between accessors and "normal methods" is a bad idea. A method is a method; it's a member function that has some specific effect. The fact that a member function simply sets the value of a member variable, or returns the value of a member variable, is an implementation detail.
And a good API isolates the outside world from implementation details. The outside world should neither know nor care that a particular function is just an accessor, if for no other reason than the fact that this can change.
Let's say you have a
name"property" in your class. Originally, you store it as astd::string. You provide functions to get and modify the name. All well and good.Now, let's say that you decide to change how the name is stored. You need to parse the name into a first name and a last name. Does the outside world need to know you're doing this? The name of your setter method doesn't need to change. It's interface doesn't need to change. All that needs to change is how you implement the function.
Google's Style guide does not represent C++ or its programmers; it only represents what Google does.