Question 18 of 26: Anti-Patterns

Question 18: Anti-Patterns (Part III)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Definition. An anti-pattern is the negative mirror of a design pattern (Question 13): a commonly-occurring, documented, NAMED solution to a recurring design problem that appears attractive or expedient in the moment — usually because it is the path of least resistance under time pressure — but that is demonstrably counterproductive, generating more technical debt, complexity, or maintenance cost than it saves. Like a genuine pattern, an anti-pattern is repeatedly observed across many independent projects (which is why it has a name at all); unlike a genuine pattern, cataloguing it is meant to help engineers RECOGNIZE and AVOID it, together with a documented refactored solution.

1. God Object (a.k.a. God Class / Blob). A single class accumulates a large fraction of the system's responsibilities, state, and behaviour, while most other classes become thin data holders that this one class manipulates directly. It arises because adding "just one more" responsibility to an already-central class is always locally easier than designing a proper new collaborator with its own well-defined interface (Question 12's design-goal trade-offs, resolved by always favouring short-term convenience). It is an anti-pattern because it directly violates single-responsibility and information-hiding (Question 19): the class becomes a single point of coupling for nearly every change, is difficult to unit-test in isolation (Question 19's testability argument — there is no small, focused unit left to test), and its sheer size makes it hard for any one engineer to hold its behaviour in their head, sharply raising defect rates.
2. Spaghetti Code. Code with no discernible control-flow structure or architecture — deeply nested conditionals, extensive reliance on shared global state, and ad hoc control transfers grown incrementally, patch by patch, with no refactoring pass to consolidate the accumulating branches. It arises for the same reason as God Object: adding another special-case branch to already-tangled code is locally the fastest way to ship one more feature, and nothing forces a stop to assess the design as a whole (exactly the architectural-erosion danger of undisciplined agile development flagged in Question 5). It is an anti-pattern because each additional patch increases the code's accidental complexity and coupling roughly combinatorially with the number of prior patches, so comprehension and defect risk grow much faster than the feature count actually delivered — eventually making even a small, well-understood change disproportionately expensive and risky to make safely.

Both qualify as anti-patterns under the same test: each is a widely-recognized, RECURRING response to a recurring problem (excess responsibility needs a home; a fixed algorithm needs one more special case) that looks like the cheapest solution in the moment, yet the documented, catalogued alternative (decompose God Object along single-responsibility lines; refactor Spaghetti Code toward Template Method/Strategy-style structured control flow, per Question 15/17) is known to cost less over the system's actual lifetime.