Effective C ++ Item 23首选成员函数的非成员非朋友函数 [英] Effective C++ Item 23 Prefer non-member non-friend functions to member functions

查看:118
本文介绍了Effective C ++ Item 23首选成员函数的非成员非朋友函数的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

虽然对类设计的一些事实感到困惑,特别是函数是否应该是成员,我研究了Effective c ++,发现了Item 23,即将非成员非朋友函数优先于成员函数。首先用Web浏览器示例读取一些意义,但是在该示例中方便的函数(在这本书中命名为非成员函数)改变了类的状态,不是吗?

再仔细看一下,他认为STL函数和某些类没有实现的某些函数在stl中实现。根据这本书的想法,他们演变成一些方便的函数,它们包装在一些合理的命名空间中,例如 std :: sort std :: copy 算法。例如向量类没有排序函数,并且使用stl sort 函数,因此不是向量类的成员。但是也可以将相同的推理延伸到向量类中的一些其他函数,例如 assign ,以便也不能作为成员实现,而是作为方便函数。然而,它也改变对象的内部状态,如它操作的排序。那么这个微妙但重要(我猜)问题背后的理由是什么。




如果您有权访问该图书,您可以为我更多地说明这些问题吗?

解决方案

访问这本书并不是必要的。



这里是依赖关系重用



在设计良好的软件中,



在设计良好的软件中,您可以应用 DRY ,以便减少依赖,因为依赖是在需要更改时需要克服的障碍。 >原则(不要重复你自己),因为当需要改变时,它是痛苦和容易出错的,必须重复它在十几个不同的地方。



经典OO心态在处理依赖性方面越来越糟糕。通过有很多方法直接依赖于类的内部,最轻微的改变意味着整个重写。



在C ++中,STL(而不是整个标准库)的设计目标是:




  • 切割依赖项

  • 允许重用



因此,容器暴露出明确定义的接口,隐藏它们的内部表示,但仍然提供对它们封装的信息的充分访问,从而可以对它们执行算法。



例如,如果你考虑 sort 的要求, code>算法。对于STL使用的实现(一般来说),它需要(从容器):







因此,任何人都可以随意访问提供随机访问和非关联的容器(理论上)适合于通过(例如)快速排序算法有效地排序。



C ++中的容器是什么




  • 基本C阵列

  • deque

  • 向量



如果你注意这些细节,任何你的容器都可以写。



这将是浪费,不会,



请注意,例如,如果您要对其进行重新编写(复制/粘贴/调整)是一个 std :: list :: sort 方法。为什么?因为 std :: list 不提供随机访问(非正式 myList [4] 不起作用) code> sort 不适合。


While puzzling with some facts on class design, specifically whether the functions should be members or not, I looked into Effective c++ and found Item 23, namely, Prefer non-member non-friend functions to member functions. Reading that at first hand with the web browser example made some sense, however convenience functions( named the nonmember functions like this in the book) in that example change the state of the class, are not they?

  • So, first question, should not they be members than?

  • Reading a bit further, he considers the STL functions and indeed some functions which are not implemented by some classes are implemented in stl. Following the ideas of the book they evolve into some convenience functions that are packed into some reasonable namespaces such as std::sort, std::copy from algorithm. For instance vector class does not have a sort function and one uses the stl sort function so that is not a member of the vector class. But one could also stretch the same reasoning to some other functions in vector class such as assign so that could also not be implemented as a member but as a convenience function. However that also changes the internal state of the object like sort on which it operated. So what is the rationale behind this subtle but important (I guess) issue.

If you have access to the book can you clarify these points a bit more for me?

解决方案

Access to the book is by no mean necessary.

The issues we are dealing here are Dependency and Reuse.

In a well-designed software, you try to isolate items from one another so as to reduce Dependencies, because Dependencies are a hurdle to overcome when change is necessary.

In a well-designed software, you apply the DRY principle (Don't Repeat Yourself) because when a change is necessary, it's painful and error-prone to have to repeat it in a dozen different places.

The "classic" OO mindset is increasingly bad at handling dependencies. By having lots and lots of methods depending directly on the internals of the class, the slightest change implies a whole rewrite. It need not be so.

In C++, the STL (not the whole standard library), has been designed with the explicit goals of:

  • cutting dependencies
  • allowing reuse

Therefore, the Containers expose well-defined interfaces that hide their internal representations but still offer sufficient access to the information they encapsulate so that Algorithms may be executed on them. All modifications are made through the container interface so that the invariants are guaranteed.

For example, if you think about the requirements of the sort algorithm. For the implementation used (in general) by the STL, it requires (from the container):

  • efficient access to an item at a given index: Random Access
  • the ability to swap two items: not Associative

Thus, any container that provides Random Access and is not Associative is (in theory) suitable to be sorted efficiently by (say) a Quick Sort algorithm.

What are the Containers in C++ that satisfy this ?

  • the basic C-array
  • deque
  • vector

And any container that you may write if you pay attention to these details.

It would be wasteful, wouldn't it, to rewrite (copy/paste/tweak) sort for each of those ?

Note, for example, that there is a std::list::sort method. Why ? Because std::list does not offer random access (informally myList[4] does not work), thus the sort from algorithm is not suitable.

这篇关于Effective C ++ Item 23首选成员函数的非成员非朋友函数的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆