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

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

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

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

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

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

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

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

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

Принципы SOLID:

Тематические статьи

Принцип программирования DRY — don’t repeat yourself / не повторяйте себя

Следование принципу DRY позволяет добиться высокой сопровождаемости программного продукта: внесение изменений и тестирование значительно упрощаются.

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

веб-разработка
бэкенд
фронтенд
методологии разработки
Статья опубликована в 2018 и обновлена в 2023 году

SOLID — принципы объектно‑ориентированного программирования

SOLID это аббревиатура пяти основных принципов проектирования в объектно‑ориентированном программировании, предложенных Робертом Мартином:

  • Single responsibility — принцип единственной ответственности
  • Open-closed — принцип открытости / закрытости
  • Liskov substitution — принцип подстановки Барбары Лисков
  • Interface segregation — принцип разделения интерфейса
  • Dependency inversion — принцип инверсии зависимостей
веб-разработка
методологии разработки
бэкенд
Статья опубликована в 2019 и обновлена в 2023 году

Принцип программирования YAGNI — «Вам это не понадобится»

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

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

методологии разработки
веб-разработка
бэкенд
фронтенд
Статья опубликована в 2019 и обновлена в 2023 году

Принцип программирования KISS — делайте вещи проще

KISS — это принцип проектирования и программирования, при котором простота системы декларируется в качестве основной цели или ценности.

Большая часть программных систем необосновано перегружена практически ненужными функциями, что ухудшает удобство их использование конечными пользователями, а также усложняет их поддержку и развитие разработчиками. Следование принципу KISS позволяет разрабатывать решения, которые не обладают этими недостатками: они просты в использовании и в сопровождении.

методологии разработки
фронтенд
бэкенд
веб-разработка
Статья опубликована в 2019 и обновлена в 2023 году

Стандарты кодирования — залог хорошей сопровождаемости проекта

Любая командная разработка может быть эффективной только в том случае, если участники команды имеют общее видение.

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

методологии разработки
веб-разработка
бэкенд
фронтенд
Статья опубликована в 2014 и обновлена в 2023 году

TDD — разработка через тестирование

TDD, test-driven development или разработка через тестирование — это методология разработки ПО, повышающая надёжность и сопровождаемость проектов.

TDD основывается на повторении коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется программный код, который реализует желаемое поведение системы и позволяет пройти написанный тест, а после этого проводится рефакторинг написанного кода с постоянной проверкой прохождения тестов.

автоматизированное тестирование
тестирование
TDD
методологии разработки
Статья опубликована в 2014 и обновлена в 2023 году

Наши услуги