Чому ISP спрощує рефакторинг?

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

Детальніше:

#1. Менше місць, куди потрібно вносити зміни

Коли інтерфейс маленький і спеціалізований, його зміна торкається лише тих реалізацій, які дійсно використовують цей контракт. "Товстий" інтерфейс - десятки залежних класів - один змінений метод ламає весь проєкт.

#2. Прозоріша архітектура

Маленькі інтерфейси відображають чіткі ролі ("друкує", "сканує", "логує"). Під час рефакторингу легко визначити, яка ділянка системи за що відповідає. З "товстими" інтерфейсами доводиться розбиратися, яка частина стосується якої відповідальності.

#3. Простіше повторно використовувати й підміняти реалізації

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

#4. Уникнення непотрібної функціональності в класах

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

#5. Локалізація змін

Маленькі інтерфейси означають, що зміна в одній функціональній зоні не торкається іншої. Наприклад, зміна логування не повинна змінювати інтерфейс і класи, відповідальні за мережеве API.

#6. Стабільні контракти

Якщо інтерфейс занадто великий, його зміна відбувається часто - кожна команда чи функціональність впливає на нього. Коли інтерфейси маленькі, вони стабільніші, а стабільні контракти - основа безпечного рефакторингу.

#7. Спрощує декомпозицію при перенесенні в мікросервіси чи модулі

Розділені інтерфейси легше виділяти в окремі модулі - кожен відповідає за свою "мікрофункцію".

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