Prefer Writing Non-member Non-friend Functions

Avoid membership fees. Where possible, prefer making functions non-member, non-friends.

• Improve encapsulation by minimizing dependencies: The body of the function cannot come to depend on the non–public members of the class.

• Reduce coupling, by breaking apart monolithic classes to liberate separable functionality.

• Improve genericity, because it is hard to write templates that don’t know whether or not an operation is a member for a given type.

Here is an algorithm to determine whether a function should be a member and/or a friend:

If the function is one of the operators =, ->, [], or (), which must be members:
=> Make it a member

Else if:
    a) the function needs a different type as its left-hand argument (as do stream operators, for example);
or b) it needs type conversions on its leftmost argument;
or c) it can be implemented using the class's public interface alone:
=> Make it a non-member (and friend if needed in cases a) and b) )

If it needs to behave virtually:
=> Add a virtual member function to provide the virtual behavior, and implement the non-member in terms of that

Else:
=> Make it a member