Разработка сайтов включает в себя работу со множеством стержневых компонентов: создание органичного макета, написание качественного контента и внедрение того, что остаётся за кадром – WEB-технологий. Все эти составляющие очень тесно взаимосвязаны друг с другом и изменение одной из них, часто влечёт за собой необходимость внесения поправок в другие. Поэтому специалисты нашей компании Pandora Research при разработке интернет-страниц, уже заранее пишут их программный код с ориентировкой на потенциальную оптимизацию в будущем. При таком подходе клиент получает на выходе продукт, который отличается гибкостью и устойчивостью.

Мы строим сайты опираясь на грамотное программирование, в котором учитываются фундаментальные принципы объектно-ориентированного программирования SOLID. Одним из таких пунктов является SRP или принцип единственной ответственности. Давайте рассмотрим его применение более детально.

Каждый класс должен иметь одну атомарную ответственность

Возьмём для примера вождение автомобиля новичком. Очень часто так бывает, что на первых порах начинающий не может вслепую находить правильное положение рукоятки переключения передач. Он вынужден отводить взгляд от дороги, и опускать глаза вниз. Таким образом его зрение имеет более одной ответственности и пока обучение проводится на учебной площадке, всё остаётся терпимым. Но при выезде на трассу подобный стиль вождения даёт сбой и начинающему придётся переучиваться заново. Это происходит потому, что класс принимает на себя более одной ответственности – его обязанности пересекаются с другими операндами.

В скриптах наблюдается аналогичная зависимость. Рассмотрим в качестве примера схему, представленную на рис. 1. Здесь класс Rectangle используется двумя приложениями одновременно: геометрическим калькулятором и графическим редактором.

Рисунок 1 Более чем одна ответственность

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

Нарушение SRP вызывает несколько неприятных проблем:

• Во-первых, мы должны расширить код геометрического калькулятора, прописав в нём алгоритм синхронизации с графическим редактором, а затем развернуть его в пользовательском интерфейсе.
• Во-вторых, если поправки в приложении для графики вызовут изменение Rectangle, то мы будем вынуждены исправить, протестировать и повторно развернуть геометрический калькулятор. Иначе он может выйти из строя в любой момент.

Поэтому лучше всего дифференцировать функции одну от другой при помощи добавления второго дополнительного класса, как это показано на рис. 2. В данном интерфейсе математические задачи Rectangle передаются классу GeometricRectangle. Теперь любая оптимизация графической части не затронет математическую.

Рисунок 2 Дифференцированные обязанности

Что такое ответственность?

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

Например, рассмотрим интерфейс, представленный в таблице 1. Большинство из нас согласятся, что в нём всё выглядит вполне разумно: четыре функции, которые объявляет класс Modem безусловно, принадлежат модему.

Таблица 1

Однако здесь завуалированы две смежные обязанности:

• Первая – это управление подключением (функции набора номера и завершения соединения).
• Вторая – передача данных (отправка и получение информации).

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

Рисунок 3 Отдельный интерфейс модема

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

Разделение интерфейсов

Обратите внимание, что на рис. 3 класс Modem Implementation выполняет сразу две атомарные функции. Это нарушает принцип единичной ответственности, но может быть необходимо. Очень часто по-другому поступить нельзя в связи с конфигурацией оборудования или ОС. Однако, в таком случае концепцию SRP в отношении всего приложения можно по-прежнему сохранить, разделив сами интерфейсы. Ведь все зависимости вытекают только из класса Modem Implementation. Поэтому остальная программная часть не должна обращаться к нему – тогда весь алгоритм останется валидным.

Сохранение стабильности

На рис. 4 показано распространённое нарушение SRP. Класс Employee содержащий часто обновляемые бизнес-правила, оказывается привязанным к подсистеме постоянства. Это грубая ошибка, порождающая проблемы при любом изменении в клиенте.

Рисунок 4 Связывание устойчивости

К счастью, стандартная работа над программными продуктами подразумевает обязательное тестирование, которое позволяет разделить эти две области задач задолго до того, как весь алгоритм будет закончен. Иначе придётся проводить реорганизацию уже в финале по чужим шаблонам.

В заключение

Таким образом представленные примеры наглядно демонстрируют, что SRP достаточно прост в понимании, но сложен в реализации. Все остальные принципы программирования на нём базируются. Ведь достаточно сложно выявить и алгоритмически дифференцировать между собой смежные функции.

Поэтому разработка веб-приложений требует большого опыта, глубоких знаний и профессиональных наработок. Специалисты нашей компании Pandora Research обладают этими важными компетенциями. Они создадут для вас интернет-страницы, которые будут надёжно функционировать и выполнять поставленные задачи в течении долгого времени.