Functional Decomposition
This is when classes are split not by functional level but by parts of a business process, which results in a very degenerate architecture.
This is when the back end is dragged onto the front end and vice versa: the front end is shoved somewhere inside the back-end classes. This is when a balance inquiry suddenly opens a connection to some web service, when a function that adds two numbers builds a pretty report for the operator, and so on.
Symptoms
- Classes are named after business-process steps rather than their role.
- Layers (UI, logic, data) are mixed together.
- Tiny "procedural" methods instead of meaningful objects.
- Side effects (network, reports, database) are scattered across the code.
Example
Here is a simple example of functional decomposition. We're not going to weigh the pros and cons of OOP here — this is just a simple demonstration of how a procedural solution makes understanding harder.
The procedural version of the loan calculation for a client — the "bad" variant:
The object-oriented version of the loan calculation for a client — the "good" variant:
Why it happens
Untangling such code when it spans the whole project is a great adventure. Usually this happens when the project has a few juniors and nobody to act as the architect. Or when developers quickly hack together an MVP expecting the code to be thrown away tomorrow, and it ends up being used for years. Sometimes I see it in the code of outsourcing companies that save developers' time.
How to fix it
- Split code by layers and responsibility, not by process steps.
- Move side effects (network, storage) outside the business logic.
- Start by defining domain objects and their behaviour.
The bottom line is that a system built this way can hardly be refactored. You have to live with it and gradually turn it into a blob.