4. Принцип персональной ответственности

Приложение, выполняющее геометрические вычисления		Rectangle
		+ draw() + area(): double				приложение
		V
			Графический интерфейс пользователя

Рис.1 В описанном проекте нарушается принцип персональной ответственности (SRP). На класс Rectangle возлагаются две ответственности. Смысл первой ответственности заключается в реализации геометрии прямоугольника. Суть вто­рой ответственности заключается в представлении прямоугольника средствами графического интерфейса пользователя. Нетрудно заметить, что в данном случае нарушается принцип персональной ответственности (SRP). В результате появляется ряд проблем. Во-первых, придет­ся включать класс GUI в приложение, реализующее геометрические вычисления. Во-вторых, в случае, если изменение GraphicalApplication приводит к модифицированию Rectangle, потребуется повторно сформировать, протести­ровать и развернуть ComputationalGeometryApplication. Если эти этапы пропущены, это может привести к непредсказуемому сбою в работе приложения. В этом проекте вычислительные операции моду­ля Rectangle выполняются классом GeometricRectangle. Теперь измене­ния, влияющие на способ отображения прямоугольника, не затрагивают ComputationalGeometryApplication.

Приложение, выполняющее			Графическое
геометрические вычисления			приложение
\	'		\	1		\	1
Geometric Rectangle			Rectangle			Графический интерфейс
+ area(): double						пользо	Вателя

В контексте SRP-принципа ответственность определяется в качестве "причи­ны для изменения". Если существует несколько мотивов для изменения класса, ему соответствует более одной ответственности. Порой этот факт не так уж про­сто распознать. Чаще имеют в виду ответственность, распределяемую в группах.

нарушение принципа SRP

interface Modem {

public void dial(String pno);

public void hangup();

public void send(char c);

public char recv(); }

Здесь представлены две ответственности. Суть первой ответственности за­ключается в управлении соединением. Вторая ответственность заключается в осу­ществлении передачи данных. Функции dial и hangup управляют соединени­ем, устанавливаемым модемом, а функции send и recv обеспечивают передачу данных. . Если применяемые при этом методы вли­яют на сигнатуру функций, устанавливающих соединение, проект станет излишне "закрепощенным". Это связано с тем, что классы send и recv придется компи­лировать и повторно использовать гораздо чаще, чем следовало бы. В этом случае следует разделять две ответственности. С другой стороны, если при изменении приложения не применяются способы, приводящие к изменению двух ответственностей в различное время, разделять их вовсе не требуется. В противном случае мы имели бы дело с избыточной сложностью. Из всего сказанного напрашивается вполне логичный вывод. Ось изменения является таковой лишь в том случае, если изменения действительно происходят. Следует применять принцип SRP только в том случае, когда это оправдано. На рис. 1 рассматриваются две ответственности, спаренные в классе Modemlmplementation. Это не всегда желательно, но иногда может быть необходимо. Весьма часто возникают причины, связанные с аппаратным обеспечением или операционной системой, принуждающие к вы­полнению спаривания. В этом случае благодаря разделению интерфейсов можно разделять концепции таким образом, чтобы не затрагивать остальные компоненты приложения. Класс Modemlmplementation можно рассматривать как некое искусствен­ное образование. Обратите внимание на то, что все зависимости протекают вне этого класса. Зависимость от этого класса не является обязательной. В этом слу­чае никакой другой модуль, исключая main, не нуждается в знании относительно существования этого класса. В результате возможные неприятности ограждают­ся своеобразным "барьером". Благодаря этому не "загрязняется" остальной код приложения.

I		Employee
Подсистема обеспечения уотойчивости
	<	+ Calculate Pay + Store

На этом рис. демонстрируется общий случай нарушения принципа SRP. Класс Employee включает деловые правила, а также обеспечивает контроль устойчи­вости. Эти две ответственности практически никогда не смешиваются. Деловые правила могут достаточно часто изменяться, и хотя то же самое нельзя сказать относительно устойчивости, изменение последней происходит в силу совершенно иных причин. Связывание деловых правил с подсистемой обеспечения устойчи­вости может привести к появлению определенных проблем.