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

Принцип единственной ответственности — The Single Responsibility Principle или SRP — один из пяти основных принципов объектно-ориентированного программирования и проектирования SOLID, описанных Робертом Мартином.

Принцип декларирует, что каждый объект должен иметь одну обязанность, и эта обязанность должна быть полностью инкапсулирована в класс, а все его сервисы должны быть направлены исключительно на обеспечение этой обязанности.

Следование принципу заключается обычно в декомпозиции сложных классов, которые делают сразу много вещей, на простые, ответственность которых очень специализирована. Но также и объединение в отдельный класс однотипной функциональности, которая может оказаться распределённой по многим классам, может рассматриваться как следование этому принципу.

Проектирование классов с направленностью на обеспечение единственной обязанности упрощает дальнейшие модификации и сопровождение, так как проще разобраться в одном блоке функциональности, нежели распутывать сложные взаимосвязи между различными модулями. Также при модификации логики в одном месте приложения снижаются риски возникновения проблем в других «неожиданных» его частях.

Следование SRP — весьма полезная практика с точки зрения повторного использования кода. Сложные объекты с комплексными зависимостями обычно трудно использовать повторно, особенно если нужна только часть реализованных в них функций. А небольшие классы с чётко очерченной функциональностью, напротив, проще использовать повторно, так как они не избыточные и редко тянут за собой существенный объём зависимостей.

Наиболее ярким антипаттерном, нарушающим принцип единственной ответственности, является использование God‑объектов, которые «слишком много знают» или «слишком много умеют». Возникают такие «божественные объекты» обычно из‑за любви разработчиков к абстракции — если возводить её в абсолют, то вполне можно любой объект реального мира отразить в приложении в виде экземпляра некоего универсального класса. На словах это даже может выглядеть логично, но на практике почти всегда приводит к проблемам сопровождаемости. Обычно такие объекты становятся центральной частью системы, а их модификация крайне сложна, так как трудно предсказать, как изменение кода для решения текущей задачи может сказаться на ранее реализованной функциональности.

Но, как и любые другие принципы, SRP требует сознательного и осмысленного применения. Чрезмерная декомпозиция может оказаться и вредной, если она приводит к большей сложности или усложняет сопровождение.

Например, часто используемый во фреймворках паттерн ActiveRecord нарушает принцип единственной ответственности. ActiveRecord действительно объединяет в себе очень много функциональных возможностей и нередко смешивает бизнес‑логику и работу со слоем хранения. При этом использование ActiveRecord часто является удобным и целесообразным. На этом примере становится ясно, что SRP — это не догма, а нарушение этого принципа вполне может быть логичным и целесообразным.

Принципы SOLID:

• Принцип единственной ответственности
• Принцип открытости / закрытости
• Принцип подстановки Барбары Лисков
• Принцип разделения интерфейса
• Принцип инверсии зависимостей