It’s important to keep design patterns in the front of your mind when you’re writing code, especially if you’re a bit rusty and are hammering code out to get back into the game, as it were. Much like someone who treats their deity’s rules and regs as a more of a general guideline, the untimely invocation of a god (class) can cause a spot of trouble.
In an effort to rekindle those parts of my brain whose job it is to turn problems into code, I have started writing an application that, while small in nature, encompasses some interesting concepts such as being modular and scripting. My initial plan was that I would get a firm understanding and then see what I could put together later, the problem is that it started to go quite well and now I want to keep it; an eventuality that I hadn’t prepared for.
Thanks largely to how well the .NET framework wraps up complex system tasks, it’s really easy to write stable and well behaved code. The code I had already written was wrapped in appropriate error handling, it had unit tests and such, but as I added more I noticed that the separation of concerns wasn’t right and would end up affecting encapsulation; the core of the application had turned into a god class, a class which knows too much and does too much. Methods were wildly coveting their neighbour’s internal details, a problem which would surely cause me to have to violate encapsulation if I continued down this path of wickedness.
Thankfully I hadn’t got very far before I noticed this lapse. After a short refactor, I have gotten rid of the god class. Though I suspect that I’ll end up with a few managers, they are usually unavoidable.