OOP - Do I over complicate things?

Question

I was looking at some of my projects and comparing them to things I've seen on github and I feel like I over-think things. I like OOP but I feel like I make too many files, too many classes.

For example, on a small project I had of a game of checkers, I had so many files that could maybe all go into one file/class. How do I know when I have over-thought my solutions? Here is what some of my files look like;

|src
| |- player.cpp
| |- piece.cpp
| |- color.cpp
| |- ...

And of course, there are many more files that will deal with things like rules, setting the game, GUI, etc,. But in this short example you can see how my projects can and will get very large. Is this common, to write things in this way? Or should I simply write a player.cpp file that either contains multiple classes that, in this case, are related and would set pieces/colors/king information, etc,.

Answer 1

People tend to worry a lot about "too many classes" or "too many files", but that's largely a historical carryover. 40 years ago when we wrote programs on punch cards, and had to carry large trays and boxes of them (and not drop them!), this certainly would have been a concern. 35 years ago when the biggest hard drive you could get for a PC was 33MB, this was a concern. Today, when you wouldn't consider buying a PC with less than 512GB of SSD, and have access to terabytes and petabytes of online storage, the number of files and number of bytes taken up by the programs are essentially immaterial to the development process.

What that means to us humans is that we should use this abundance of capacity to improve other aspects of our code. If more files helps you understand the code better, use more files. If longer file names help you understand the code better, use longer file names. If following a rule like "one .cpp and one .h file per class" helps people maintain the codebase, then follow the rule. The key is to focus on truly important issues, such as "what makes this code more maintainable, more readable, more understandable to me and my team?"

Another way to approach this is to ask if the "number of files" is a useful metric for determining if code is maintainable? While a number that is obviously too low for the app would be concerning, I wouldn't be able to tell you if 10 or 100 or 1000 was an appropriate number (at least without knowing the number of classes they contain.) Therefore, it doesn't appear to be a useful metric.

Does that mean a program should have 1000 files all piled into a single folder, all compiling and linking into a single library or executable file? It depends, but it seems that 1000 classes in the same namespace would be a bit crowded and the resultant program might be too monolithic. At some point you'll probably want to refactor the architecture into smaller, more cohesive packages, each with an appropriate area of responsibility. Of course, nobody can tell you what that magic number is, as it's completely application dependent. But it's not the number of files that drives a decision like this, it's that the files should be related to each other logically or architecturally.

Answer 2

You are actually asking two distinct questions: "what is the good granularity for separating functionality into classes" and "what is the good practice to organize project file structure". Both are rather broad.

The answer to first one would probably be to follow a single responsibility idiom. The answer to second one would be to make folder structure resemble the namespace structure (like in boost for example). Your current approach with storing everything in src folder is not good for C++ because it will lead to longer file names to prevent names collision when classes with the same name appearing in different namespaces. Larger projects indeed tend to have too many files as one class would require 4-5 files. And that leads to yet another question of selecting appropriate granularity for projects...

Answer 3

Yes, distributing your code to multiple files is a good practice, since it makes your project maintainable.

I can see your concerns on a small project (is the overhead worth it?), but in real big projects, if you don't do it that way, you will end up with people scrolling forever in a large file, and using searching trough the file to find out what they are looking for.

Try to keep your files compact, and one class per file, where every class is robust and its goal is clear.

Sometimes, we write functions to files. It would not be wise to have a file for every small, inline function, it will increase the number of files without a reason. It would be better to have a family of functions inside a file (functions related to printing for example).

At the end, it's probably opinion based which is the ideal balance between size and number of files, but I hope I made myself clear.

Answer 4

Each class should be designed and programmed to accomplish one, and only one, thing Because each class is designed to have only a single responsibility, many classes are used to build an entire application