Чому "товсті" інтерфейси шкідливі?

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

Детальніше:

#1. Клієнти залежать від методів, які їм не потрібні

Якщо інтерфейс містить 10 методів, а клієнт використовує лише 1-2, він змушений залежати від усієї десятки. Будь-яка зміна в цих методах торкнеться клієнта, хоча функціонально він до них не належить. Це підвищує зв'язаність і порушує стійкість системи.

#2. Реалізації змушені підтримувати зайву поведінку

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

#3. Зміни в інтерфейсі призводять до масових змін у коді

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

#4. Зменшується можливість повторного використання

Товстий інтерфейс важко використовувати повторно - він прив'язаний до занадто великого набору методів. Таке API стає негнучким і перевантаженим.

#5. Складніше тестувати окремі модулі

Коли інтерфейс містить десяток методів, тестований об'єкт або:

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

#6. Порушується принцип єдиної відповідальності (SRP)

Товстий інтерфейс майже завжди містить методи, що належать до різних зон відповідальності. Це веде до плутанини і непередбачуваної поведінки.

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