Friday 1 April 2016

Splitting up classes

I have had a tendency to create big classes which are one of problems in this project. Along with SDL2 refactor I've started to split up big classes by removing some features to new classes. Things like automap displaying was previously in Gui class which is kind of thematically correct, because it only contains displaying, but at the same time it's adding up to complexity of the Gui class.

Sometimes creating extra classes can be more work (and code), but it's most likely a better option anyway. Classes can be split up by theme, but in deeper level it becomes easier to split small classes also with inheritance. This is sometimes a natural result of classes becoming small, because you can then either derive from that class or even derive to "upward" direction which means it's possible to create another base class for classes that have same kind of structure.

Being able to create a base class that way is great, because it's making the source code shorter and easier to manage, although in perfect world you should be able to design the class hierarchy before it's refactored this way. I think the way biggest problem with classes are the size and growing number of functions in the class. Yet it's always a trade-off. Big complex classes can do more than small simple classes, but they are much harder to use as classes. A big class can become more like a small program in the program and working with it can be difficult especially when you need to rewrite the code.

I hope the process of elimination becomes easier when I split classes by theme, because that is the way I'm programming this project.

No comments:

Post a Comment