interface-segregation_skill

Overview

This skill helps designers and implementers apply the Interface Segregation Principle (ISP) in TypeScript projects. It identifies when an interface is too large, shows how to split fat interfaces into focused capabilities, and explains why throw/no-op implementations are a design smell. The goal is to ensure types express capabilities so implementations only promise what they can deliver.

How this skill works

The skill inspects interfaces and implementations to detect the "throw/no-op" smell and other red flags (large interfaces, supports() checks, unused methods in implementers). It recommends splitting a fat interface into small, cohesive interfaces (1–3 methods ideally) and shows patterns for composing capabilities. It also offers suggested responses and actions when pressured to accept or ship violations.

When to use it

• Designing a new interface or API surface in TypeScript
• Implementing an interface and forced to throw or no-op for some methods
• Refactoring a codebase where different implementers use different subsets of an interface
• Reviewing interfaces with more than ~5–7 methods
• When callers use runtime capability checks like supportsX()

Best practices

• Prefer many small, focused interfaces over one fat interface
• Aim for 1–3 methods per interface; 4–5 only if highly cohesive
• Never implement an interface method with throw or an empty body
• Use type composition (A & B) for callers that need multiple capabilities
• Propose refactoring existing fat interfaces rather than adding runtime checks

Example use cases

• Splitting a MultiFunctionDevice into Printer, Scanner, Fax so BasicPrinter doesn't implement unused methods
• Refactoring a Repository<T> into Readable<T> and Writable<T> when some services only read
• Rejecting a PR that implements unsupported methods by throwing and requesting segregated interfaces
• Replacing supportsX() runtime checks with distinct interfaces so the compiler enforces capabilities
• Designing a new service API and modeling individual responsibilities as separate interfaces