Як визначити, що клас або модуль порушує SRP?

Порушення SRP визначається через аналіз того, скільки різних причин можуть призвести до зміни одного й того самого класу чи модуля. Основні ознаки такі:

#1. Клас виконує логічно різні завдання

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

#2. Зміни в різних областях системи зачіпають один і той самий клас

Якщо клас доводиться змінювати при:

• зміні бізнес-правил,
• зміні вимог до звітності,
• зміні формату вводу/виводу,
• значить, у нього кілька «причин для зміни».

#3. Методи не пов'язані єдиною концепцією

Коли методи класу не об'єднує одна мета. Наприклад, в одному класі є і calculatePrice(), і saveToDatabase(). Це різні зони відповідальності: розрахунок і зберігання.

#4. Клас починає розростатися, з'являються умовності

Часті ознаки:

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

#5. Складно написати ізольовані тести

Якщо тестування класу вимагає мокати безліч непов'язаних залежностей (БД, пошта, логер), значить, він відповідає за занадто багато.

#6. Назва класу стає надто широкою

Коли назва типу Manager, Processor, Helper, Utils, «сервіси на всі випадки життя» - це майже завжди порушення SRP, тому що клас не описує одну роль.

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