什么时候应该是成员函数？ [英] When should functions be member functions?
问题描述
我在公司里有一个同事，他的意见我非常尊重，但我根本不明白他在C ++中编写代码的首选风格。
I have a colleague in my company whose opinions I have a great deal of respect for, but I simply cannot understand one of his preferred styles of writing code in C++.
例如，假设有一些类A，他将编写以下类型的全局函数：
For example, given there is some class A, he'll write global functions of the type:
void foo( A *ptrToA ){}
或：
void bar( const A &refToA ){}
我第一次看到这样的全球性功能的本能是：为什么A不是这些成员？他会坚持下来，这与C ++中的良好实践的建议是一致的，因为foo和bar可以通过使用A的公共接口执行他们需要执行的所有操作。例如，他会认为这是完全一致的与Scott Meyers有效的C ++建议。我发现很难与该书中的项目19协调，其基本上说，一切都应该是具有少数例外（运算符<<和运算符&和需要动态类型转换的函数）的成员函数。此外，虽然我同意这些功能可以做他们需要做的与A的公共接口，在我看来，这主要是人们编写的类有getter和setters为A类的每个数据成员的结果。所以，公共接口，A是一个过度的结构，你当然可以做任何事情与公共接口。个人而言，我不认为应该利用它，我认为应该不鼓励。
My first instinct upon seeing global functions like that is: "Why aren't these members of A?" He'll insist up and down that this is consistent with recommendations for good practice in C++, because foo and bar can perform all they need to perform by using the public interface of A. For example, he'll argue that this is completely consistent with Scott Meyers Effective C++ recommendations. I find it hard to reconcile this with item 19 in that book which basically says everything should be a member function with a few exceptions (operator<< and operator>> and functions that need dynamic type conversion). Furthermore, while I agree that the functions can do what they need to do with the public interface of A, in my opinion, that's largely the result of people writing classes that have getters and setters for every data member of class A. So with that public interface, A is an over-glorified struct and you certainly can do anything with the public interface. Personally, I don't think that should be exploited, I think it should be discouraged.
显然，这只有在像C ++这样的不是纯对象面向对象，所以我猜测一种方式是我的同事不喜欢纯粹的面向对象的方法来进行软件设计。有谁知道任何支持这个职位作为最佳实践的文献？或者任何人都同意这一点，并可以解释它与我不同的方式，我的同事，以便我可以看到光？
Obviously, this is only possible in a language like C++ that is not pure object oriented, so I guess one way of looking at it is that my colleague does not favor a pure object oriented approach to software design. Does anyone know of any literature that supports this position as a best practice? Or does anyone agree with this and can possibly explain it to me in a different way than my colleague has so that I might see the light? Or does everyone agree with my current feeling that this just doesn't make much sense?
编辑：
让我给一个更好的代码示例。
Let me give a better code example.
class Car
{
Wheel frontLeft;
Wheel frontRight;
Wheel rearLeft;
Wheel rearRight;
Wheel spareInTrunk;
public:
void wheelsOnCar( list< Wheel > &wheels )
{
wheels.push_back( frontLeft );
wheels.push_back( frontRight);
wheels.push_back( rearLeft);
wheels.push_back( rearRight);
}
const Wheel & getSpare(){ return spareInTrunk; }
void setSpare( const Wheel &newSpare ){ spareInTrunk = newSpare; }
// There are getters and setters for the other wheels too,
//but they aren't important for this example
};
然后我会看到一个这样的函数：
Then I'll see a function like this:
void wheelsRelatedToCar( Car *aCar, list< Wheel > &wheels )
{
aCar->wheelsOnCar( wheels );
wheels.push_back( aCar->getSpare() );
}
这是一个真正的示例，类和函数的名称改变了。为什么会想要 wheelsRelatedToCar 不是Car的成员函数？在这个真实的例子中，Car和Wheel在同一个图书馆。全局函数在使用该库的特定应用程序中的源文件中定义，因此，作出了该函数特定于应用程序的参数。我的回答是，这是一个完全合法的操作上的车，属于Car类。是否有另一个角度去看它（除了一个不喜欢使用面向对象设计的人）？
This is a real example with the names of the classes and functions changed of course. Why would one want wheelsRelatedToCar to not be a member function of Car? In this real example, Car and Wheel were in the same library. The global function was defined in a source file in a specific application using that library, so the argument was made that the function was specific to the application. My response was that it was a perfectly legitimate operation on the Car and belonged with the Car class. Is there another perspective to look at it (other than one who does not prefer to use object oriented design)?
推荐答案
Scott Meyers提倡非成员函数经常改进封装：
Scott Meyers has advocated that non-member functions often improve encapsulation:
- How Non-Member Functions Improve Encapsulation
Herb Sutter和Jim Hyslop也谈到了这一点（引用Meyer的文章）在自助标头中
Herb Sutter and Jim Hyslop also talk about this (citing Meyer's article) in "Self-Sufficient Headers"
- http://www.ddj.com/cpp/184401705
这些提案已重新发布）在 Meyer的Effective C ++第三版中，第23项：成员最喜欢非会员非朋友功能函数和 Sutter / Alexandrescu的C ++编码标准，44 - 首选写非成员非友函数。
These ideas have been republished (in more refined form) in the 3rd edition of Meyer's "Effective C++", "Item 23: Prefer non-member non-friend functions to member functions ", and Sutter/Alexandrescu's "C++ Coding Standards", "44 - Prefer writing nonmember nonfriend functions".
我认为很多开发人员发现这种非直观的，也许有点争议。
I think a lot of developers find this non-intuitive and maybe a little controversial.
这篇关于什么时候应该是成员函数？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
