code-architecture-wrong-abstraction

Use the rule of three to decide when to abstract code: wait until a pattern appears three times before extracting shared utilities. This prevents premature generalization and keeps code clear.

Avoid wrong abstractions by prioritizing clarity over premature generalization. Use concrete guardrails to evaluate whether extracting a shared utility actually simplifies the codebase before refactoring.

Yes, premature abstraction erodes clarity in multi-file software projects. Extracting shared utilities too early creates rigid structures that are harder to modify than the original duplicated code.

Evaluate refactoring tasks by checking if the abstraction satisfies rule-of-three criteria. Extract shared utilities only when real-world patterns justify the generalization, ensuring DRY principles are applied correctly.

Aggressive DRY application fails because premature generalization couples unrelated modules through wrong abstractions. Keeping code duplication is often clearer than forcing a shared utility prematurely.