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

Single Responsibility Principle, он же Принцип единой ответственности, в дальнейшем просто SRP.

Термин SRP был введён Робертом С. Мартином в одноимённой статье как часть SOLID, ставших популярными благодаря его книге "Быстрая разработка программ. Принципы, примеры, практика. ".

Каждый класс должен решать лишь одну задачу.

Да-да, именно так. По сути, это основной смысл данного правила(принципа), который, мы разберем сегодня.

Каждый класс должен отвечать за что-то конкретное, то есть, класс должен быть ответственен лишь за что-то одно. Если же класс отвечает за решение нескольких задач, это создает проблему изменения и поддержки такой системы или подсистемы, так как изменение логики для чего-то конкретного, может сломать что-то совершенно другое, что каким-то образом оказалось в этом классе. путем - "Исторически так сложилось".

Разберем на примере :

Допустим, мы делаем автоматизацию получения данных раз в n-ое время. У нас есть класс, который парсит эти данные. У него есть методы получения данных, преобразования полученных данных в JSON и сохранения этих данных. Казалось бы, замечательно. Однако появляется необходимость расширения функционала. Создается класс. Новый класс работает с API, получает определенные данные, и так же сохраняет их в БД. Разработчик, берет метод для сохранения данных из класса, который парсит данные. Проходит время, и метод сохранения данных нужно поменять. Разработчик меняет это в одном классе, но не делает этого в другом. Возникает проблема. Да, верно, тут мы затронули тему DRY(не повторяйся), но это имеет смысл для данного принципа. Разработчик, который не следует SRP, не сможет поддерживать систему адекватно. будут постоянно баги, которые все тяжелее будет отслеживать.

В данном случае метод сохранения данных у обоих классов является излишнем и нагружает поддержку и читаемость такого кода. Если же за работу с БД будет отвечать отдельный класс, это будет удобно. изменил в одном месте и работает как надо. (P. S. метод преобразования полученных данных в JSON просто не стал описывать).

Проектируя классы, мы должны стремиться к тому, чтобы объединять родственные компоненты, то есть такие, изменения в которых происходят по одним и тем же причинам. Нам следует стараться разделять компоненты, изменения в которых вызывают различные причины. - Стив Фентон.

Правильное применение и понимание данного принципа — это есть класс, методы которого соответствуют его главной цели.

A class should have only one reason to change. Robert C. Martin.