SOLID SRP - Single Responsibility Principle - Принцип единственной ответственности

SOLID принципы: SRP

Принцип SRP расшифровывается как «Single Responsibility Principle», что переводится как «Принцип единственной ответственности». Эту закономерность называют связностью. Причем связность определяется в качестве функционального соотношения, установленного между элементами модуля (класса).

Правило SRP: существует лишь одна причина, приводящая к изменению класса.

Если в процессе создания класса или внесения изменений в существующий класс — появляется необходимость разделить данный класс на два класса, с целью разделения ответственности между ними.

В чем же смысл передачи двух ответственностей различным классам? Скорее всего, это связанно с тем, что каждая ответственность представляет собой своего рода «ось изменений». В случае изменений требований, производится изменение ответственностей, распределенных между классами. Если на класс возложено несколько ответственностей, возникает ряд причин для их изменений.

Если все же классу соответствует несколько ответственностей, производится их спаривание. В случае изменения одной ответственности — затрудняется или становится невозможным соответствие класса другим, возложенным на него ответственностям. В результате формируется «хрупкий» проект, который может разрушится непредвиденным образом после выполнения каких-либо изменений.

Пример

Примером, для понимания принципа единственной ответственности, служит описание работы класса — Rectangle, который представляет собой абстракцию описывающую математическую сущность прямоугольника, где его потребители:

  • графический вывод прямоугольника — GraphDevice;

  • геометрические вычисления с использованием класса прямоугольника — GeomCalc.

Схема ниже демонстрирует потребителей данного класса:

SOLID принципы: SRP - Принцип единственной ответственности

Очевидно, что класс Rectangle включает в себя методы:

  • draw — для рисования прямоугольника;

  • area — для вычисления площади фигуры.

Как видно, два разных класса используют класс Rectangle. Один из этих классов реализует вычислительную геометрию (GeomCalc). При этом все математические вычисления, производимые над геометрическими фигурами, выполняется с помощью класса Rectangle. Причем этот класс «не способен» к графическому выводу прямоугольников. Другой класс (GraphDevice) по своей природе отвечает за графическое представление прямоугольника — он может также реализовывать некоторую вычислительную геометрию, но главное его предназначение заключается в рисовании прямоугольников.

В описанном проекте нарушается принцип персональной ответственности (SRP). На класс Rectangle возлагается две ответственности. Смысл первой ответственности заключается в реализации геометрии прямоугольника. Суть второй ответственности заключается в представлении прямоугольника средствами графического вывода.

Исходя из данного нарушения принципа SRP, имеем следующие проблемы:

  1. в случае изменения класса GraphDevice мы будем по тем или иным причинам вынужденны вносить изменения в класс Rectangle — что потребует дополнительного времени и затрат;

  2. в случае изменения класса GeomCalc мы будем также вынуждены по тем или иным причинам вносить изменения в класс Rectangle, что также неприемлемо.

Поэтому нам необходимо разделить класс Rectangle на два отдельных класса — унаследованных от базового класса Rectangle, как показано на схеме ниже:

SOLID принципы: SRP - Принцип единственной ответственности

Таким образом мы разделили наш первоначальный перегруженный класс Rectangle на два отдельных класса:

  • RectangleGeom — класс отвечающий за геометрические вычисления над прямоугольником;

  • RectangleGraph — класс отвечающий за графическое представление прямоугольника.

Резюме

В контексте SRP-приниципа — ответственность определяется в качестве «причины для изменения». Если существует несколько мотивов для изменения класса, то ему соответствует более одной ответственности.

Злоупотреблять SPR не стоит, т. к. это порой может привести к излишней сложности проекта и необоснованностью потраченного времени на «расщепления» классов. Но стоит учитывать следующий момент: ось изменения является таковой лишь в том случае, если изменения действительно происходят. Другими словами — следует применять принцип SRP только в том случае, когда это оправданно.

Оставить ответ