Using "friend" classes in game development

Question

Typically in C++ game development speed is valued over encapsulation, you therefore see a ton of publicly accessible class members which really shouldn't be public.

I seem to find in most cases that only a very select few clases really need to known the inner workings of another classes to the point of modifying or reading their private data.

Creating public getters/setters for this private data exposes things which really shouldn't be modified willy-nilly.

Would a compromise here be to use friend classes? or is there some drawback to friend classes I'm not seeing.

Answer 1

There are two major drawbacks to friending classes.

1. You can't pick and choose what you want to expose to your friends. It's all or nothing. This can prove problematic if you're trying to enforce mandatory use of some kind of non-inconsequential setter.
2. Your two classes are now somewhat coupled in the sense that the friend-er knows about the friend.

That being said, using friend classes can definitely improve encapsulation, especially if the alternative is public getters/setters.

Also, related question on SO: https://stackoverflow.com/questions/521754/when-to-use-friend-class-in-c

Answer 2

Encapsulation is nice, but separation of concerns is nicer.

A class accessing "some private part" of other class could indicate that the code isn't well designed in the first place.

Every time you find yourself in the "gosh, I need to make a friend class here" spot, the question you should ask yourself is "am I doing this correctly, or is there a cleaner way?" (a.k.a. "Is this going to bite me in the ass later on?").

If you are sure about the "friendliness", put it there without hesitation.

Answer 3

Another option is to use the PIMPL idiom, where part of the structure's implementation is a pointer to another type. Most users of the class will just include the normal header file, where the implementation is an opaque pointer. Classes that need access to the private data can include the header defining the other type, and use the interface it provides.

This a common pattern for C programmers wanting friend-like functionality. In my opinion it also hews more closely to thinking about separation of concerns (a generally good design principle that leads to reusable, orthogonal code) rather than encapsulation (an OO-specific technique that is useful for implementing separation of concerns, but also often misused to overcomplicate things).

It has an advantage over friend that it doesn't couple the friend-er to the friend-ee at all. Some people might claim that's a disadvantage, since now anyone can "friend" your class. I think that's an unwarranted fear, since you're still making the relationship explicit (by including the header). If you're afraid of that, you're afraid of your (or your coworker's) ability to make smart architectural decisions. But if you can't make those decisions properly later, why are you trusting yourself with friend now?

It has a disadvantage of runtime cost. By storing the data in a pointer you have worse cache coherency and more allocation counts, and you also need a destructor to clean it up.