What are demerits of friend function?

Answer 1

The only demerit of a friend function is when it is used inappropriately. The first thing to remember with friends is that they are privileged -- they have unrestricted access to the private members of a class. Therefore it would be unwise to allow such access to a function that you have absolutely no control over. However, it is equally unwise to permit a function to have unrestricted access when it has no need for that access. If the public interface of a class is sufficient, then the function has no business being a friend.

Many people will tell you that friends undermine the fundamental concepts of encapsulation and data-hiding. Quite frankly this is errant nonsense and shows a complete misunderstanding of what friendship means. A friend no more undermines data-hiding than does the class itself. Class member methods are highly-privileged in that they have unrestricted access to the private members of ANY instance of the class, not just the current instance. If friends are said to undermine data-hiding and encapsulation then surely the same must be said of the class, to a much higher degree.

Far from undermining data-hiding and encapsulation, they actively enforce it. Unfortunately, the majority of examples that are said to back this up actually do the exact opposite. Remember, if a public interface exists and is sufficient, then use it, otherwise you really are undermining data-hiding and encapsulation.

But consider this: if a function cannot be implemented within the class itself (as a member method) and the function cannot work with the current public interface of the class, then you will be faced with just two options: either you grant the function friend access, or you alter the public interface to suit the function. If you alter the public interface, not only does the function have access to that interface, but you also expose that interface to ALL external functions. That alone will do far more to undermine any concept of data-hiding and encapsulation than if you just gave the function friend access. At least then the exposure is limited only to that one friend, and not to all and sundry.

So what would be a good example of a friend function? Imagine you have a parent class that can contain one or more instances of a child class and the child class contains a private member pointer to its parent. To add a child to a parent you might call a Parent::InsertData() method, which creates a new child for the given data and sets the child's parent to itself via a Child::SetParent() method. But if the parent can set a child's parent pointer, then what's to stop some errant code from altering that pointer? That alone would undermine the encapsulation we hold so dear.

So the SetParent() method must be made private, which means the parent can no longer update the child's parent pointer. The only remaining solution is to declare the Parent::InsertData() method as a friend of the child class. This then allows that one function (and only that function) to alter the parent pointer of a child from outside of the child class itself. And since the parent and child classes are inextricably bound together anyway, all you've really done is extend the child's interface without exposing the interface to all and sundry.

Encapsulation and data-hiding are not compromised in any way as the Parent::InsertData() method is now encapsulated as part of the child class interface; it has the same access rights as the child class itself. And if the child class can act responsibly with regards to its own instance data (as well as the data of other instances of the child class) then surely the same can be said of the Parent::InsertData() method. And even if that method passed the child to another function for further processing, that function would not have friend access to the child.