Разделение интерфейса

Принцип разделения интерфейса: ни один клиент не должен быть вынужден зависеть от методов, которые он не использует. «Зависеть от» — несущая формулировка. Клиент зависит от каждого метода в интерфейсе, который он именует, — не только от тех, что вызывает, — потому что компилятор, проверка типов, мок-фреймворк и следующий читатель видят всю поверхность. Модуль отчётов, типизированный против восемнадцатиметодного IUserRepository, для всех практических целей привязан ко всем восемнадцати.

// One fat contract every consumer is forced to name in full.
interface IUserRepository {
  findById(id: string): Promise<User | null>;
  search(q: Query): Promise<User[]>;
  create(u: NewUser): Promise<User>;
  update(id: string, patch: Partial<User>): Promise<User>;
  delete(id: string): Promise<void>;
  bulkImport(rows: CsvRow[]): Promise<ImportReport>;
  exportAuditTrail(id: string): Promise<AuditEvent[]>;
  eraseForGdpr(id: string): Promise<void>;
  warmCache(): Promise<void>;
  // …nine more
}

Отчёт использует два из них. ISP говорит: он не должен даже знать, что остальные шестнадцать существуют.

Толстый интерфейс связывает несвязанных клиентов через тип, а не через их поведение. Экран отчётов и конвейер импорта не делят ни логики, ни потока данных, ни требования. Но раз они именуют один интерфейс, правка, которую требует один, прилетает к другому. Добавь bulkImportStreaming(stream) для импортёра — и мок отчёта больше не удовлетворяет интерфейс; его файл перекомпилируется; CI перезапускает его тесты; ревьюер обязан заново его одобрить. Ничто из того, что отчёт делает, не изменилось — изменилась лишь форма, от которой его заставили зависеть.

// The importer's new requirement…
interface IUserRepository {
  // …
  bulkImportStreaming(stream: ReadableStream): Promise<ImportReport>; // NEW
}

// …breaks this, which never imports anything:
class FakeRepoForReportTests implements IUserRepository {
  // ❌ now missing bulkImportStreaming — report tests fail to compile
}

Это и есть магнит связанности: чем шире интерфейс, тем больше несвязанных клиентов стягивается вместе и тем чаще каждого тревожит изменение, в котором у него не было никакой доли.

Разбивай на ролевые интерфейсы, названные по тому, как клиент использует тип. Не называй интерфейсы по реализации (IUserRepository); называй их по роли, которая нужна клиенту, — по срезу возможностей, который данный потребитель разыгрывает против типа. Отчёту нужно искать пользователей, поэтому он зависит от UserLookup. Импортёру нужно записывать их массово, поэтому он зависит от UserImporter. Конкретный репозиторий по-прежнему реализует всё; клиенты просто перестают видеть дальше собственной роли.

interface UserLookup {
  findById(id: string): Promise<User | null>;
  search(q: Query): Promise<User[]>;
}

interface UserWriter {
  create(u: NewUser): Promise<User>;
  update(id: string, patch: Partial<User>): Promise<User>;
  delete(id: string): Promise<void>;
}

interface UserImporter {
  bulkImport(rows: CsvRow[]): Promise<ImportReport>;
}

// One class can satisfy several roles at once.
class UserRepository implements UserLookup, UserWriter, UserImporter { /* … */ }

Теперь отчёт зависит от UserLookup — два метода, ровно тот срез, который он использует. Импортёр может растить UserImporter сколько угодно, а отчёт ни перекомпилируется, ни перетестируется.

Типизируй клиент против узкой роли — и развязка станет настоящей. Разделение интерфейса окупается, только если потребители действительно именуют узкий тип. Отчёт, который всё ещё принимает IUserRepository «для удобства», снова зависит от всего. Дисциплина такова: сигнатура каждого потребителя объявляет ровно ту роль, которую он разыгрывает.

// Before: bound to the whole surface, coupled to 16 unused methods.
function buildReport(repo: IUserRepository) { /* uses 2 */ }

// After: the signature is the dependency declaration.
function buildReport(repo: UserLookup) {
  return repo.search({ active: true });
}

Отдача конкретна и senior-уровня: тестовый дубль для buildReport стабит два метода, а не восемнадцать; сигнатура честно документирует зависимость; а изменение ролей записи/импорта/GDPR не может дотянуться до этой функции, потому что система типов больше их не соединяет. Разделение позволяет каждому клиенту зависеть только от нужного ему среза.