Programming is about solving problems and almost every problem is solvable and more easy to handle by breaking it up into smaller pieces. This trick is called divide and conquer and in order to become a better programmer you should master it.
When you are designing a method, you should keep it as tight as possible so that it only does exactly what the method name says it’s doing. The smaller and nimbler the pieces you are working with are, the easier they will be to reuse for different purposes.
Once you have a class with miniscule methods, you will have to take a good look at the class itself. What does it do? Can you sum it up and not use the word “and”? If you can all is good and well, otherwise it might be too big. Create a new class with everything that you can describe as after your “and” until the class is slimmed down. If you have methods that are needed by both classes, create a utility class with only those methods and slim down your classes even more.
By having small classes and small methods inside of them you are actually saving your self a lot of trouble by avoiding accidental complexity. Your small classes interfaces will be clean and simple to work with. Having classes that only do specific things should enable you to go to the next step of your divide and conquer plan, bundling.
Imagine having all your classes at the same level, it would be a nightmare! Every time you ask your IDE to get a method or class it would suggest everything, all the time! Instead divide your classes into packages or folders that does certain things in your domain. If classes are calculating and presenting information to your economy department, why not name one folder “Economy” and have subfolders for different activities inside it. Don’t go so far as to put graphic classes into a subfolder called “graphics” or you’ll end up having to open up your accessors too much, let classes that handle one activity stay together.
You can keep separating things even as you keep going up in your hierarchy, you can even to them on an architectural level, ever heard of microservices? Why would you want a big old monolith of a program when you can get everything in small simple programs dedicated to only one thing. Sounds a lot like what we did to our structure before! We make sure nothing is inside that doesn’t belong there.
One great benefit of working with microservices is that you and your team can work on one part and another team can work on something else without having to worry about messing up each others code. The idea is to always add a new microservice if you need something. Never modify existing code.
As you can see what we have done is fairly simple. We keep everything that needs to be together in the same place and move everything else out of the scope. We do this on every level; method, class, folder and program.