Would it be practical if I used composition for everything?

Question

I've been learning C++ and SDL2 and I'm trying to improve at using composition and for the longest time I thought it was only useful for making things like players, enemies, coins, etc, and I think part of it is because of my understanding of the word "entity" but after some experimenting where I made my camera an "entity" that had some camera specific components, I realized that technically anything could make use composition since to my understanding the point of composition is making a class out of a bunch of smaller classes.

So now I've been thinking if it would be practical to actually use composition for everything. For example, I have a level manager which is just a basic/normal object that parses an XML file and draws the tiles to the screen would it be beneficial to break things into components such as a tile loader component or would doing this be unnecessary?

Answer 1

Composition is a tool. Always use the right tool for the job.

Of course you can use a screwdriver to hit a nail. But using a hammer might lead to faster and cleaner results.

Composition is a pretty powerful and flexible tool. Some popular game engines (like Unity, for example) are built around the concept. But that doesn't mean that it is the best tool for every situation. There are problems that are easier to solve with a singleton system approach. Or where inheritance leads to a cleaner and more flexible design.

I've tried to build games in the past where I tried to fanatically cling to one specific pattern. OOP inheritance, everything communicating through a message bus, Entity-Component-System or whatever else was the main subject of the last article on software architecture I read. Sooner or later I always stumbled upon architectural problems where following my one chosen pattern was just ridiculously counter-productive and I decided to diverge from it.

Answer 2

Yes you could! And many people would. However it’s quite possible to go too far where you have hundreds of tiny components that don’t really do anything themselves and it becomes hard to remember which components need which other ones to combine together properly.

A good rule of thumb is to only break up large components when you need to. Whether it’s because the class is getting too long/ difficult to read, or it’s doing too many things, it’s hard to refactor etc.

A kind of heuristic that I use which has served me fairly well, is that if a class starts approaching 200+ lines. I take a quick look to see if I notice any obvious components hiding inside the big one. If not, that’s fine. When a class gets to the 500+ range, there’s almost always something in there screaming to be let out.

It helps to makes sure you add checks to warn you if you are missing a particular component that another depends on.something as simple as a little console message saying “Missing component X in ___”