duplication-vs-abstraction

Evaluate duplicated code for refactoring into shared abstractions using the Rule of Three.

2.1k|36|Updated Feb 4, 2021
One-click install
npx skills add https://github.com/recyclarr/recyclarr --skill duplication-vs-abstraction
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: duplication-vs-abstraction
Source: https://github.com/recyclarr/recyclarr/tree/main/.opencode/skills/duplication-vs-abstraction
Command: npx skills add https://github.com/recyclarr/recyclarr --skill duplication-vs-abstraction

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill provides a framework to help developers make informed decisions about whether to refactor duplicated code into a shared abstraction or to keep them separate, preventing premature or incorrect abstractions.

Core Features & Use Cases

  • Decision Framework: Offers a structured checklist to guide the abstraction decision.
  • DRY Principle Clarification: Emphasizes that DRY applies to knowledge, not just syntax.
  • Rule of Three Guidance: Recommends abstracting only after encountering three or more instances.
  • Cost-Benefit Analysis: Helps evaluate the true cost of an abstraction versus the cost of duplication.
  • Code-Generated Types Handling: Provides strategies for dealing with similar types generated by different tools.
  • Anti-Corruption Layer Considerations: Addresses abstraction in the context of Domain-Driven Design.
  • Use Case: When you have three similar API client adapters, this skill helps you determine if they should be unified under a single interface or kept separate.

Quick Start

Use the duplication-vs-abstraction skill to decide if the three similar code snippets should be refactored into a single abstraction.

Frequently Asked Questions about duplication-vs-abstraction

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

FAQPage Schema
When should I refactor duplicated code into a shared abstraction?

Refactor duplicated code into a shared abstraction when the duplication represents shared knowledge, not just identical syntax. Apply the Rule of Three threshold, abstracting only after three or more instances appear to ensure the cost-benefit ratio justifies the abstraction.

How do I decide between keeping parallel implementations or creating an abstraction?

Decide between parallel implementations and abstractions by performing a cost-benefit analysis. Evaluate the maintenance cost of duplicated code against the coupling and complexity introduced by a shared abstraction to determine the most sustainable software design approach.

Does the DRY principle mean all duplicated code should be abstracted?

The DRY principle applies to duplicated knowledge, not merely duplicated syntax. Code that looks similar but models different domain concepts should remain separate to avoid incorrect coupling and preserve clean code boundaries.

How to handle similar code-generated types when applying the DRY principle?

Handle similar code-generated types by keeping them separate rather than forcing a shared abstraction. Because these types are generated by different tools, unifying them often creates brittle coupling and violates domain boundaries.

When should I not unify similar API client adapters under a single interface?

Do not unify similar API client adapters if they serve different bounded contexts. Maintaining separate adapters prevents anti-corruption layer violations and keeps domain-specific logic properly isolated within Domain-Driven Design constraints.

What is the Rule of Three in software design refactoring?

The Rule of Three in software design states that you should only abstract duplicated code into a shared implementation after encountering it three or more times. This prevents premature abstractions that increase code complexity.