code-architecture-wrong-abstraction

Guide software design decisions on code abstraction using the Rule of Three.

5|Updated Oct 17, 2011
One-click install
npx skills add https://github.com/klen/dotfiles --skill code-architecture-wrong-abstraction-klen
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: code-architecture-wrong-abstraction
Source: https://github.com/klen/dotfiles/tree/main/.config/opencode/skills/code-architecture-wrong-abstraction
Command: npx skills add https://github.com/klen/dotfiles --skill code-architecture-wrong-abstraction-klen

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill helps developers make better decisions about when to abstract code and when to duplicate it, preventing the creation of complex and hard-to-maintain codebases due to premature or incorrect abstractions.

Core Features & Use Cases

  • Guidance on Abstraction: Provides clear principles like the "Rule of Three" to determine when abstraction is beneficial.
  • Identifying Wrong Abstractions: Illustrates common pitfalls and patterns of "wrong abstraction," particularly with the Facade pattern.
  • Refactoring Strategies: Offers practical advice on how to fix existing wrong abstractions by inlining code and re-extracting when patterns stabilize.
  • Use Case: When refactoring a feature, you notice similar logic in two different places. This Skill guides you on whether to abstract now or wait for a third instance.

Quick Start

Use the code-architecture-wrong-abstraction skill to understand when to abstract code versus when to duplicate it.

Frequently Asked Questions about code-architecture-wrong-abstraction

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
What is premature abstraction in code architecture and why is it a problem?

Premature abstraction occurs when developers generalize code before patterns stabilize, creating hard-to-maintain codebases. It forces incorrect couplings between unrelated features, making future modifications risky and complex instead of simplifying the architecture.

Should I follow DRY principles or duplicate code when refactoring?

While DRY reduces duplication, embracing WET (Write Everything Twice) or AHA (Avoid Hasty Abstraction) principles initially is safer. Duplicating code early on prevents wrong abstractions, allowing you to wait until the true pattern emerges before refactoring.

How do I refactor a wrong abstraction in a facade pattern?

Refactor wrong abstractions by inlining the problematic facade code back into its callers. Once inlined, observe the duplicated logic and re-extract new abstractions only when the design stabilizes and clear patterns re-emerge.

When should I avoid using the facade pattern in software design?

Avoid the facade pattern when underlying subsystems are still evolving or when it prematurely hides logic that hasn't stabilized. Using facades too early leads to wrong abstractions that tightly couple features and hinder future codebase modifications.