Encapsulating Complexity

Design domain-oriented interfaces that hide implementation details from public APIs.

Updated Nov 27, 2025
One-click install
npx skills add https://github.com/barrydobson/dotfiles_extra --skill encapsulating-complexity
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: Encapsulating Complexity
Source: https://github.com/barrydobson/dotfiles_extra/tree/main/packages/claude/dot-claude/skills/architecture/encapsulating-complexity
Command: npx skills add https://github.com/barrydobson/dotfiles_extra --skill encapsulating-complexity

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill prevents "abstraction leaks" where internal implementation details (like database schemas, file formats, or raw data structures) are exposed through public interfaces. It ensures that client code interacts at a high-level, domain-specific "what" rather than a low-level "how," making systems more flexible, maintainable, and resilient to change.

Core Features & Use Cases

  • Information Hiding: Guides you to design interfaces that expose only what a component does, not how it achieves it.
  • Domain-Level Interaction: Encourages working with domain objects (e.g., User, Order) instead of raw data structures (e.g., dict, SQL row).
  • Implementation Agnosticism: Ensures that changing internal implementation (e.g., switching from JSON to YAML, or PostgreSQL to MongoDB) does not break client code.
  • Encapsulation Test: Provides a set of questions to rigorously evaluate if an interface is truly encapsulating its complexity.
  • Use Case: Instead of a ConfigManager that exposes json_path and save_to_json(), this skill guides you to create a Config class with get_timeout() and save() methods, hiding the underlying storage format.

Quick Start

I'm designing a UserRepository class. Guide me through applying the "Encapsulating Complexity" skill. Help me design its interface to hide the underlying database implementation (e.g., SQL queries, ORM details) and expose only domain-level operations like get_user_by_id or save_user.

Frequently Asked Questions about Encapsulating Complexity

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

FAQPage Schema
How do I hide implementation details in my API design?

Hide implementation details by designing interfaces that expose only domain-level operations, not how they work internally. Instead of exposing storage formats or raw data structures, provide methods like `get_user_by_id()` or `save()` that let clients interact at a high level without knowing whether data comes from SQL, JSON, or another format.

What's the difference between exposing the 'what' versus the 'how' in class design?

Exposing the 'what' means clients interact with domain objects and operations (e.g., `User`, `save()`), while exposing the 'how' leaks internal mechanics (database queries, storage formats). The 'what' keeps your API stable when you change implementations; the 'how' breaks client code whenever internals shift.

How do I design a repository class that doesn't expose database details?

Design repository interfaces around domain operations like `get_user_by_id()` and `save_user()` rather than SQL queries or ORM methods. Hide the underlying database technology, query structure, and storage format so clients remain decoupled and you can switch databases without breaking code that uses the repository.

Why does exposing raw data structures break maintainability?

Raw data structures (dictionaries, SQL rows, JSON objects) tie clients to specific storage formats. When you change storage—switching from PostgreSQL to MongoDB or JSON to YAML—client code breaks. Encapsulating behind domain-oriented interfaces lets you change internals freely while keeping client code stable.

Can I apply encapsulation to legacy code with tightly coupled implementations?

Yes. Start by defining domain-level interfaces that hide existing implementation details, then gradually migrate client code to use those interfaces instead of direct access. This decouples clients first, making it safer to refactor internals later without cascading breaks.

What questions should I ask to verify my interface truly hides complexity?

Encapsulation is rigorous: ask whether clients need to know storage format, whether changing databases would break them, and whether the interface exposes domain concepts or implementation mechanics. If clients must understand internal structure to use your API, complexity is still leaking.