Every software developer faces the same fundamental tension: make components specific enough to be useful, but abstract enough to be reusable. Get the balance wrong, and you end up with either an over-engineered framework that nobody understands or a pile of copy-pasted code that's impossible to maintain.

Key Takeaways

  • The Rule of Three: don't abstract until you've seen the pattern three times
  • Good abstractions hide complexity; bad abstractions just move it
  • Component boundaries should align with domain boundaries, not technical layers
  • Prefer composition over inheritance for flexible component architecture

The Abstraction Spectrum

Think of component abstraction as a spectrum from fully concrete (a function that does one specific thing) to fully abstract (a generic framework that could do anything). Most useful components sit in the middle — they handle a class of problems, not every possible problem.

The SOLID principles, particularly the Single Responsibility and Interface Segregation principles, provide a useful framework for finding this balance. A component should do one thing well, and its interface should expose only what consumers need.

Practical Guidelines

The Rule of Three

Don't create an abstraction the first time you write something. Don't create it the second time either. On the third occurrence, you have enough data points to see the real pattern. Premature abstraction is more expensive than code duplication because a wrong abstraction is harder to fix than duplicated code.

Domain-Driven Boundaries

Components should align with your domain model, not with technical layers. A "UserService" that handles authentication, profile management, and notification preferences is poorly abstracted — those are different domain concepts. Separate them into components that match how the business thinks about these concerns.

Composition Over Inheritance

Deep inheritance hierarchies are a sign of over-abstraction. If you find yourself creating AbstractBaseFactoryProvider classes, you've gone too far. Prefer composing simple components together over building elaborate class hierarchies. Modern frameworks (React, Vue, SwiftUI) have moved entirely to composition models for this reason.

Related Articles

Frequently Asked Questions

How do you know if a component is too abstract?

If developers need to read the implementation to understand how to use it, or if configuring the component takes more code than writing a specific solution would, it's likely over-abstracted. Good abstractions make common cases simple and uncommon cases possible.

What's the difference between abstraction and indirection?

Abstraction hides complexity by providing a simpler mental model. Indirection adds a layer between components, which may or may not simplify anything. Adding an interface just to have an interface is indirection without abstraction — it increases code without reducing cognitive load.