Принцип розділення інтерфейсів (ISP) — TypeScript & React

Коротко: Опануйте Принцип розділення інтерфейсів (ISP). Навчіться застосовувати SOLID на практиці з прикладами в TypeScript та React, щоб писати чистіший і простіший у підтримці код.¹

Вступ

Принцип розділення інтерфейсів (ISP) каже: клієнт не повинен залежати від методів, які він не використовує. Якщо застосувати ISP правильно, це зменшує звʼязність, спрощує тестування і робить код гнучкішим та зрозумілішим. У цьому керівництві — практичні приклади для TypeScript і React, кроки рефакторингу та правила для команд, які хочуть підтримувати здорову архітектуру та полегшити автоматичну перевірку коду.¹

Що таке Принцип розділення інтерфейсів?

Уявіть пульт від телевізора з 90 кнопками, коли потрібна лише кнопка «Відтворити». Так само й у софті: коли клас змушують реалізувати великий, розпливчастий інтерфейс, зʼявляється зайвий код і помилки. ISP заохочує проектувати малі, клієнт-специфічні інтерфейси замість одного універсального контракту. Це запобігає антипатерну «товстий інтерфейс» і робить систему гнучкішою.¹

Чому «товсті» інтерфейси шкодять

• Зайві залежності: класи звʼязані з методами, які не використовують, тому зміни в одному місці можуть поламати інше.
• Когнітивне навантаження: розробник мусить переглядати багато неважливих методів.
• Порожні реалізації: класам доводиться писати заглушки для непотрібних методів.

Головна ідея проста: дайте кожному клієнту тільки те, що йому потрібно. Це полегшує розуміння, тестування та еволюцію коду.

Монолітні проти розділених інтерфейсів

Вибір на користь ISP допомагає коду залишатися адаптованим із ростом вимог.

ISP у практиці: типові порушення

Порушення не обовʼязково ламають додаток, але ускладнюють супровід. Шукай класи з багатьма порожніми методами або компоненти з великою кількістю необовʼязкових пропсів.

Класичний «God Interface» у TypeScript

// ANTI-PATTERN: «товстий інтерфейс»
interface IUserActions {
  createUser(data: UserData): void;
  editUser(id: string, data: UserData): void;
  deleteUser(id: string): void;
  viewUserProfile(id: string): UserProfile;
  changeUserRole(id: string, newRole: Role): void;
  publishArticle(article: Article): void;
  approveComment(commentId: string): void;
}

Клас Viewer, змушений реалізувати цей інтерфейс, матиме непотрібні методи або заглушки. Це ускладнює підтримку і тестування.

Надміру великий набір props у React

// ANTI-PATTERN: надмірний інтерфейс пропсів
interface CardProps {
  title: string;
  description?: string;
  imageUrl?: string;
  imageAltText?: string;
  videoUrl?: string;
  authorName?: string;
  authorAvatarUrl?: string;
  publicationDate?: string;
  articleLink?: string;
  onClick?: () => void;
  // ... і ще багато необовʼязкових полів
}

Такий дизайн створює неоднозначність щодо допустимих поєднань пропсів і змушує писати складну умовну логіку у компоненті.

Як рефакторити: від моноліту до розділених інтерфейсів

Рефакторинг під ISP не вимагає повного переписування. Працюй маленькими кроками: визначай ролі, виділяй контрактні частини й поступово замінюй великі інтерфейси.

1) Виправлення «God Interface» у TypeScript

Крок A: визначи ролі клієнтів (наприклад, Admin, Editor, Viewer).

Крок B: створи інтерфейси для кожної ролі.

// GOOD: сфокусовані інтерфейси
interface IViewerActions {
  viewUserProfile(id: string): UserProfile;
}

interface IEditorActions {
  publishArticle(article: Article): void;
  approveComment(commentId: string): void;
}

interface IAdminActions {
  createUser(data: UserData): void;
  editUser(id: string, data: UserData): void;
  deleteUser(id: string): void;
  changeUserRole(id: string, newRole: Role): void;
}

class Viewer implements IViewerActions {
  viewUserProfile(id: string): UserProfile {
    console.log(`Fetching profile for user ${id}...`);
    // ... fetch and return profile
  }
}

Адміністратор може імплементувати кілька інтерфейсів одночасно. Такий поділ зменшує кількість непотрібних залежностей і робить контракти очевидними.

2) Рефакторинг пропсів React через дискриміновані обʼєднання

Використай дискриміновані юніони, щоб кожен варіант компонента мав чіткий контракт. TypeScript добре підходить для цього.²

// GOOD: базові пропси
type BaseCardProps = {
  title: string;
  onClick?: () => void;
};

// GOOD: конкретні варіанти
type ImageCardProps = BaseCardProps & {
  cardType: 'image';
  imageUrl: string;
  imageAltText: string;
};

type ArticleCardProps = BaseCardProps & {
  cardType: 'article';
  description: string;
  authorName: string;
  articleLink: string;
};

type CardProps = ImageCardProps | ArticleCardProps;

З таким підходом IDE і компілятор одразу підкажуть дійсні поєднання пропсів і запобіжать помилкам.

Аудит і впровадження ISP у команді

Одноразових виправлень недостатньо. Щоб ISP працював довго, закріпи критерії аудиту й додай автоматичні перевірки у процес розробки.

Критерії для ревʼю

Створи чекліст для PR‑ревʼю, що дозволяє помічати ознаки порушення ISP:

• Інтерфейси з багатьма методами (варто переглянути, якщо більше 5–7).
• Порожні або заглушкові методи в реалізаціях.
• Нечіткі назви інтерфейсів із словами «Manager» або «Handler».
• Компоненти з великою кількістю необовʼязкових пропсів.

Автоматизація перевірки

ESLint і кастомні правила допомагають виловлювати очевидні проблеми, наприклад, надмірні пропси або класи з незаповненими методами.³ Поєднання автоматичних правил і людського ревʼю дає найкращий результат: інструменти забезпечують послідовність, а люди — контекст і бізнес‑логіку.

Малі інтерфейси також спрощують TDD: легше робити моки й писати чистіші юніт‑тести, що прискорює цикл Red‑Green‑Refactor.⁵

ISP та розробка з AI‑помічниками

Коли AI інструменти стають частиною робочого процесу, чіткі та вузькі інтерфейси допомагають моделям краще розуміти ваш код і давати точніші підказки чи рефакторинг. Маленькі інтерфейси зменшують неоднозначність і підвищують якість згенерованого коду.⁴

Поширені запитання

Чи означає ISP, що кожен метод повинен мати окремий інтерфейс?

Ні. Не треба дробити інтерфейси до абсурду. Групуйте методи, які завжди використовуються разом одним клієнтом. Мета — когезійні, цілеспрямовані інтерфейси, а не фрагментація.

Чим ISP відрізняється від Single Responsibility Principle (SRP)?

SRP про класи: кожен клас має одну причину для зміни. ISP про інтерфейси: клієнти не повинні залежати від непотрібних методів. Можна дотримуватись SRP, але порушувати ISP, якщо клас імплементує занадто великий інтерфейс.

Коли можна ігнорувати ISP?

Коли не можна змінити інтерфейс (наприклад, стороння бібліотека) або коли всі клієнти дійсно потребують усіх методів — тоді більший інтерфейс може бути доречним.

Швидкий чек‑ліст для рефакторингу

• Визначте ролі і клієнтів для кожного інтерфейсу.
• Розбийте великі інтерфейси на роль‑специфічні контракти.
• Використовуйте дискриміновані юніони для варіантів компонентів у TypeScript.²
• Додайте eslint‑правила для виявлення надмірних інтерфейсів і пропсів.³
• Поєднуйте автоматичні перевірки з код‑ревʼю для складніших рішень.

Три короткі запитання й відповіді

Q: Як швидко знайти порушення ISP?

A: Шукайте інтерфейси з багатьма незвʼязаними методами, класи з порожніми реалізаціями або компоненти з десятками необовʼязкових пропсів — це ознаки, що інтерфейс варто розбити.

Q: Який найшвидший спосіб виправити «товстий інтерфейс»?

A: Визначте клієнтські ролі, створіть роль‑специфічні інтерфейси й поступово оновлюйте реалізації, щоб вони імплементували лише потрібні контракти.

Q: Як уникнути повернення проблеми при зростанні кодової бази?

A: Впровадьте lint‑правила й CI‑перевірки для базових патернів, а також додайте чекліст для ревʼю щодо дизайну інтерфейсів.

У матеріалах Clean Code Guy ми допомагаємо командам застосовувати принципи на практиці, щоб створювати підтримувані й AI‑готові кодові бази. Замовте аудит коду, щоб знайти приховані проблеми і підвищити якість супроводу.