Premature Abstraction
Premature abstraction—adding layers of indirection, classes, and generic architectures before the problem is well understood—is argued to create brittle, opaque systems that are harder to change than straightforward procedural code. Commenters contrast OO, FP, and data-focused design, warning particularly against deep inheritance hierarchies and speculative generality, while advocating incremental architecture: start with simple, concrete solutions, then introduce abstractions only when recurring patterns and domain concepts are genuinely clear. Many note that good abstractions simplify mental models and data structures, but bad ones merely relocate complexity and couple unrelated concerns.
What “Abstraction” Means
- Strong tension between “abstraction as unifying concept” vs “abstraction as extra layer of code.”
- Several argue that moving common methods into base classes is usually indirection or “concretion,” not true abstraction, because it ties many callers to one specific implementation.
- Others counter that sharing a common method via a superclass is abstraction if it captures a genuine commonality; the key test is whether it simplifies the mental model, not just code reuse.
Inheritance, Interfaces, and Code Smells
- Many horror stories of deep or wide inheritance hierarchies where every change affects the whole system.
- Criticism of:
- Huge base-class webs (e.g., “Book extends Shelfable, Readable, …”).
- Interfaces with only one implementation.
- Over-architected plugin-style inheritance when composition or simple functions would do.
- Some defend interfaces/traits as powerful when small and generic (e.g., Rust traits, Go interfaces), but emphasize that finding good ones is hard.
OO vs FP vs Procedural for Domain Modeling
- One camp: OO is good for domain modeling if you mostly bundle data + behavior, minimize inheritance, and keep state well-encapsulated.
- Another camp: OO domain models become fragile as business rules change and subtyping breaks substitutability; dynamic dispatch obscures behavior for readers.
- FP/ADT proponents argue functional domain modeling (algebraic data types, pattern matching) yields clearer, more explicit models and makes complexity visible.
- Others note FP can also over-abstract and push too much indirection; dogmatic FP isn’t a silver bullet.
Incremental Architecture & “Post-Architecture”
- Broad agreement on starting with simple procedural code and evolving structure:
- Begin with straightforward functions and data.
- Extract helpers, then group related operations into modules/classes when duplication or complexity appears.
- Keep side effects isolated (“imperative shell, functional core”).
- Some note that in certain Java/C# environments (e.g., banking) heavy up-front architecture and generics are still common and often painful.
Premature Abstraction vs Primitive Obsession
- “Premature abstraction” is likened to the “speculative generality” smell: generic abstractions invented before needs are known, producing confusing indirection.
- Others warn against the opposite extreme (“primitive obsession”): never introducing domain types (e.g., Money, PersonName) and overusing raw primitives.
- Consensus: abstractions should simplify and be introduced when real pressures (duplication, rigidity, unclear code) emerge, not just because a pattern exists.