Technical Debt and God Class

No, I am not trying to bring in spirituality to coding although sometimes we do blame God for our bugs :) I was reading about reducing technical debt (cost of work due to poor approaches or solutions chosen earlier) through automation and machine learning when I first heard about the God class. God class unlike the positive vibe the name has (to theists at least), is not the best thing for technical debt. It is a class that has far too many methods and attributes than it should have. It is a class that “knows everything” hence the name.

How does it come about?

When people and projects are under pressure, they contribute to technical debt. Code is written where instead of taking a long time view of things, patches are added to fix bugs. Instead of following the Single Responsibility Principle, where “every class should have only one reason to change”, there are classes that have multiple responsibilities eventually leading to become the god class.

Here is a simple example of a god class. This class’ responsibility is to hold order details but as can be seen it also has attributes for item and price. This can be expanded to show other attributes related to shipping and other supply chain aspects.

With corresponding getter/setter methods and any business logic thrown in, this class would become unwieldy and difficult to maintain. The right way would be to have classes based on responsibilities, where order, item and price would be separate classes as shown below.

When do we refactor?

If there are bugs reported or new features asked for, rather than just doing the needful, take the opportunity to refactor the code. For a small additional effort, there would be the return of getting rid of technical debt and preventing normal classes from becoming god classes or as someone had mentioned a Monster class!