Принцип єдиної відповідальності

Принцип єдиної відповідальності[1] (англ. Single Responsibility Principle, SRP) — важливий принцип об'єктно-орієнтованого програмування, який означає, що клас має бути створений для виконання лише однієї задачі, яку він повинен повністю інкапсулювати. Отже, всі сервіси цього класу мають бути повністю підпорядковані її виконанню.

SOLID
принципи об'єктно-орієнтованого проектування

Роберт Мартін, засновник терміну, висловлює принцип так: «Клас повинен мати лише одну причину для змін»[2], хоча через плутанину навколо слова «причина» він також заявив: «Цей принцип стосується людей»[3]. У деяких своїх виступах він також стверджує, що принцип стосується, зокрема, ролей чи акторів. Наприклад, хоча вони можуть бути однією людиною, роль бухгалтера відрізняється від адміністратора бази даних. Отже, кожен модуль повинен відповідати за кожну роль[1].

Історія

Термін був запроваджений Робертом Мартіном в однойменній статті як частина його принципів об'єктно-орієнтованого програмування, що поширився завдяки його книзі «Швидка розробка програм. Принципи, приклади, практика». Мартін описав її як засновану на принципі зв'язності, сформульованого Томом ДеМарко в його книзі «Structured Analysis and Systems Specification»[4].

Приклад порушення SRP

Нехай в системі є клас, що представляє в ній робітника:

public class Employee {
   private String name;
   // інші поля

  public String getName() {
      return name;
  }
  // інші методи

  public void printReport() {
      // код для друкування звіту
  }
}

Крім цього, існує можливість друкувати звіт про робітника за допомогою методу printReport(). Це і є порушення SRP.

Для прикладу, розглянемо випадок зміни формату звіту. Це змусить програмістів редагувати printReport(), що, можливо, призведе до зміни робочого коду, що відповідає за представлення робітника. Та навпаки, якщо у клас буде додано будь-яка нова функціональність, наприклад поле telNumber, то ці зміни будуть впливати на вміст звіту. А редагуючи вміст, можна зачепити формат звіту.

Очевидно, що проблема полягає в багатоцільовому Employee. Тому її рішення буде наступним — розділити його функціональність, наприклад так:

public class Employee {
   private String name;
   // інші поля

  public String getName() {
      return name;
  }
  // інші методи
}

public class Reporter {
  public void printReport(Employee worker) {
      // код для друкування звіту
  } 
}

Переваги та недоліки

Серед плюсів варто відмітити такі:

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

Мінус використання полягає в зростанні кількості класів, що приводить до зростання складності системи.

Використання

SOLID — буква «S» означає принцип єдиного обов'язку (англ. Single Responsibility Principle).

Див. також

Примітки
  1. Мартін, Роберт (2019). Розділ 13. Зв'язність компонентів: Принцип узгодженої зміни. Чиста архітектура: Мистецтво розроблення програмного забезпечення. «Ранок», Фабула. с. 125–126. ISBN 978-617-09-5286-8.
  2. Мартін, Роберт (2021). Чистий Agile. «Ранок», Фабула. с. 224. ISBN 978-617-09-6760-2.
  3. Martin, Robert C. (2014). The Single Responsibility Principle. The Clean Code Blog.
  4. DeMarco, Tom. (1979). Structured Analysis and System Specification. Prentice Hall. ISBN 0138543801.

Посилання
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.