Premature Abstraction

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.