非成员函数如何改进封装

问题描述

我阅读了 Scott Meyers 的文章，但对他在说什么感到很困惑关于.我在这里有 3 个问题.

I read Scott Meyers' article on the subject and quite confused about what he is talking about. I have 3 questions here.

问题 1

为了详细解释，假设我正在编写一个简单的 vector 类，其中包含 push_back、insert 和运算符 等方法>[].如果我遵循 Meyers 的算法，我最终会得到所有非成员友元函数.我将拥有一个包含很少私有成员和许多非成员友元函数的向量类.这是他在说的吗?

To explain in detail, assume I am writing a simple vector<T> class with methods like push_back, insert and operator []. If I followed Meyers' algorithm, I would end up with all non-member friend functions. I will have a vector class with few private members and many non-member friend functions. Is this what he is talking about?

问题 2

我仍然不明白非成员函数如何改进封装.考虑一下 Meyers 的文章中给出的代码.

I am still not understanding how non-member functions improve encapsulation. Consider the code given in Meyers' article.

class Point {
public:
   int getXValue() const; 
   int getYValue() const; 
   void setXValue(int newXValue);
   void setYValue(int newYValue);

private:
  ...                 // whatever...
};

如果遵循他的算法，setXXXX 方法应该是非成员的.我的问题是如何增加封装?他还说

If his algorithm is followed, setXXXX methods should be non-members. My question is how that increases encapsulation? He also says

我们现在已经看到了一种合理的方式测量封装量在一个班级里是要数可能会被破坏的功能，如果类的实现更改.

We've now seen that a reasonable way to gauge the amount of encapsulation in a class is to count the number of functions that might be broken if the class's implementation changes.

除非我们在类实现更改时保持方法签名不变，否则客户端代码不会中断并且封装得很好，对吗?这同样适用于非成员函数.那么非成员函数有什么优势呢?

Until we keep the method signature intact when class implementation changes, no client code is gonna break and it is well encapsulated, right? The same applies for non-member functions as well. So what is the advantage non-member function provides?

问题 3

引用他的算法

else if (f needs type conversions
         on its left-most argument)
   {
   make f a non-member function;
   if (f needs access to non-public
       members of C)
      make f a friend of C;
   }

他所说的f 需要在其最左边的参数上进行类型转换是什么意思?他还在文章中说了以下内容.

What he meant by f needs type conversions on its left-most argument? He also says the following in the article.

此外，我们现在看到常见的说法是朋友功能违反封装"不完全是真的.朋友不违背封装，他们只是减少它-以与会员完全相同的方式功能.

Furthermore, we now see that the common claim that "friend functions violate encapsulation" is not quite true. Friends don't violate encapsulation, they just decrease it — in exactly the same manner as a member functions.

这个和上面的算法是矛盾的吧?

This and the above algorithm are contradictory, right?

推荐答案

问题 1

在这种情况下，遵循 Meyers 的算法将为您提供成员函数:

In this case, following Meyers's algorithm will give you member functions:

• 它们需要是虚拟的吗?号
• 它们是 operator<<< 还是 operator>>?号
• 他们需要类型转换吗?号
• 它们可以在公共接口方面实现吗?号
• 所以让他们成为会员.

他的建议是只在他们真正需要的时候才让他们成为朋友；偏爱非会员非朋友胜过会员而非朋友.

His advice is to only make them friends when they really need to be; to favour non-member non-friends over members over friends.

问题 2

SetXXXX 函数需要访问类的内部(私有)表示，所以它们不能是非成员非朋友；所以，迈耶斯认为，他们应该是成员而不是朋友.

The SetXXXX functions need to access the internal (private) representation of the class, so they can't be non-member non-friends; so, Meyers argues, they should be members rather than friends.

封装是通过隐藏类的实现细节来实现的；您将公共接口与私有实现分开定义.如果您随后发明了更好的实现，则可以在不更改公共接口的情况下更改它，并且使用该类的任何代码都将继续工作.因此，Meyers 的可能被破坏的函数数量"计算了成员函数和友元函数(我们可以通过查看类定义轻松追踪)，但不会计算通过其公共接口使用该类的任何非成员非友元函数.

The encapsulation comes about by hiding the details of how the class is implemented; you define a public interface separately from a private implementation. If you then invent a better implementation, you can change it without changing the public interface, and any code using the class will continue to work. So Meyers's "number of functions which might be broken" counts the member and friend functions (which we can easily track down by looking at the class definition), but not any non-member non-friend functions using the class through its public interface.

问题 3

这已经得到解答.

从 Meyers 的建议中吸取的要点是:

The important points to take away from Meyers's advice are:

• 将类设计为具有与其私有实现分离的干净、稳定的公共接口；
• 仅在真正需要访问实现时才将函数设为成员或好友；
• 只有当函数不能成为成员时才将它们交朋友.

这篇关于非成员函数如何改进封装的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持html5模板网！