Effective C++ Item 23 Prefer non-member non-friend functions to member functions

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, don't they?

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

• 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.

The criteria I use is if a function could be implemented significantly more efficiently by being a member function, then it should be a member function. ::std::sort does not meet that definition. In fact, there is no efficiency difference whatsoever in implementing it externally vs. internally.

A vast efficiency improvement by implementing something as a member (or friend) function means that it greatly benefits from knowing the internal state of the class.

Part of the art of interface design is the art of finding the most minimal set of member functions such that all operations you might want to perform on the object can be implemented reasonably efficiently in terms of them. And this set should not support operations that shouldn't be performed on the class. So you can't just implement a bunch of getter and setter functions and call it good.

I think the reason for this rule is that by using member functions you may rely too much on the internals of a class by accident. Changing the state of a class is not a problem. The real problem is the amount of code you need to change if you modify some private property inside your class. Keeping the interface of the class (public methods) as small as possible reduces both the amount of work you will need to do in such a case and the risk of doing something weird with your private data, leaving you with an instance in an inconsistent state.

AtoMerZ is also right, non-member non-friend functions can be templated and reused for other types as well.

By the way you should buy your copy of Effective C++, it's a great book, but do not try to always comply with every item of this book. Object Oriented Design both good practices (from books, etc.) AND experience (I think it's also written in Effective C++ somewhere).

Various thoughts:

• It's nice when non-members work through the class's public API, as it reduces the amount of code that:
  • needs to be carefully monitored to ensure class invariants,
  • needs to be changed if the object's implementation is redesigned.
• When that isn't good enough, a non-member can still be made a friend.
• Writing a non-member function is usually a smidgeon less convenient, as members aren't implicitly in scope, BUT if you consider program evolution:
  • Once a non-member function exists and it is realised that the same functionality would be useful for other types, it's generally very easy to convert the function to a template and have it available not just for both types, but for arbitrary future types too. Put another way, non-member templates allow even more flexible algorithm reuse than run-time polymorphism / virtual dispatch: templates allow something known as duck typing.
  • An existing type sporting a useful member function encourages cut-and-paste to the other types that would like analogous behaviour because most ways of converting the function for re-use require that every implicit member access be made an explicit access on a particular object, which is going to be a more tedius 30+ seconds for the programmer....
• Member functions allow the object.function(x, y, z) notation, which IMHO is very convenient, expressive and intuitive. They also work better with discovery/completion features in many IDE's.

• A separation as member and non-member functions can help communicate the essential nature of the class, it's invariants and fundamental operations, and logically group the add-on and possibly ad-hoc "convenience" features. Consider Tony Hoare's wisdom:
  
  "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult."

  • Here, non-member usage isn't necessarily far more difficult, but you do have to think more about how you're accessing member data and private/protected methods and why, and which operations are fundamental. Such soul searching would improve the design with member functions too, it's just easier to be lazy about :-/.

• As non-member functionality expands in sophistication or picks up additional dependencies, the functions can be moved into separate headers and implementation files, even libraries, so users of the core functionality only "pay" for using the parts they want.

(Omnifarious's answer is a must-read, thrice if it's new to you.)