SOLID «S»: Принцип единственной обязанности 

Даже по такому простейшему примеру можно сделать вывод о том, как правильно разграничивать бизнес-логику и представление. Придерживаясь ПЕО, можно построить гораздо более гибкую архитектуру.

Объекты, которые способны «сохранять» себя

Еще один похожий на предыдущий вариант пример того, как объект может сам себя сохранять и восстанавливаться из представления.

class Book {

	function getTitle() {
		return "A Great Book";
	}

	function getAuthor() {
		return "John Doe";
	}

	function turnPage() {
		// pointer to next page
	}

	function getCurrentPage() {
		return "current page content";
	}

	function save() {
		$filename = '/documents/'. $this->getTitle(). ' - ' . $this->getAuthor();
		file_put_contents($filename, serialize($this));
	}

}

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

class Book {

	function getTitle() {
		return "A Great Book";
	}

	function getAuthor() {
		return "John Doe";
	}

	function turnPage() {
		// pointer to next page
	}

	function getCurrentPage() {
		return "current page content";
	}

}

class SimpleFilePersistence {
	function save(Book $book) {
		$filename = '/documents/' . $book->getTitle() . ' - ' . $book->getAuthor();
		file_put_contents($filename, serialize($book));
	}
}

Переместив метод сохранения объекта в другой класс, мы сможем явно разделить ответственность и легко изменить данный метод сохраняемости, никак не влияя на класс Book. Так, внедрение класса DatabasePersistence будет абсолютно тривиальным, и наша бизнес-логика, выстроенная вокруг действий с книгой никак не изменится.

Высокоуровневое представление

В своих предыдущих статьях я не раз упоминал и предлагал Вашему вниманию схему высокоуровневой архитектуры, которая приведена ниже.

Если мы проанализируем данную схему, то сразу поймем, как соблюдается ПЕО. Создание нового объекта обозначено с правой стороны схемы с помощью «Фабрик» (Factories) и единой точки входа нашего приложения (Main). Один актёр - одна ответственность. О сохраняемости (Persistence) также позаботились, расположив ее внизу. Отдельный модуль предназначается для отдельной ответственности. И наконец, с левой стороны мы разместили представление, или механизм доставки, в виде MVC или каком-либо другом типе пользовательского интерфейса. И вновь соблюден принцип единой ответственности. Все, что нам остается выяснить, - это что делать с самой бизнес-логикой.

Вопросы проектирования программного обеспечения

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

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

Изложим по шагам:

Значение первого критерия должно быть установлено до определения значения второго критерия.

1. Второй критерий отвечает за удовлетворение потребностей пользователей.
2. Потребности пользователей – это потребности актёров.
3. Потребности актёров определяют необходимость изменения этих актёров.
4. Потребности в изменениях актёров, в свою очередь, определяют нашу ответственность.

Таким образом, в процессе разработки архитектуры нашего программного обеспечения, мы должны:

1. Определить актёров.
2. Выявить область ответственности каждого актёра.
3. Сгруппировать классы и функции так, чтобы каждый из них отвечал только за свою часть.

Менее очевидный пример

class Book {

	function getTitle() {
		return "A Great Book";
	}

	function getAuthor() {
		return "John Doe";
	}

	function turnPage() {
		// pointer to next page
	}

	function getCurrentPage() {
		return "current page content";
	}

	function getLocation() {
		// returns the position in the library
		// ie. shelf number & room number
	}

}

Теперь это выглядит вполне очевидно и рационально. У нас нет метода, который относился бы к сохранению или отображению данных. Мы располагаем функционалом метода turnPage() и еще несколькими методами, позволяющими предоставить необходимые сведения о книге. Однако мы можем столкнуться с некоторой проблемой. Чтобы ее установить, давайте проанализируем наше приложение. Проблема может быть в функции getLocation().

Всем методы нашего класса Book реализуют задуманную бизнес-логику. Поэтому мы должны рассматривать свои перспективы с точки зрения задачи. Если наше приложение написано специально для использования библиотекарями, которые ищут и выдают нам реальные книги, то ПЕО может быть нарушен.

Варианты интерпретации

Мы можем сделать вывод, что методы getAuthor(), getTitle()и getLocation() могут быть нужны только для выполнения операций актеров. Посетители также могут иметь доступ к приложению для выбора книги и чтения нескольких первых ее страниц, которые могут помочь им решить, нужна ли им эта книга или нет. Следовательно, для таких актёров как читатели могут быть полезны все имеющиеся методы, кроме getLocation(), т.к. читателей не волнует, где в библиотеке хранятся нужные книги. Книгу найдет и отдаст в руки посетителя библиотекарь. Таким образом, мы действительно имеем нарушение принципа единой ответственности.

class Book {

	function getTitle() {
		return "A Great Book";
	}

	function getAuthor() {
		return "John Doe";
	}

	function turnPage() {
		// pointer to next page
	}

	function getCurrentPage() {
		return "current page content";
	}

}

class BookLocator {

	function locate(Book $book) {
		// returns the position in the library
		// ie. shelf number & room number
		$libraryMap->findBookBy($book->getTitle(), $book->getAuthor());
	}

}

Для того чтобы найти нужную книгу, библиотекарь должен будет применить класс BookLocator. Посетителю же потребуется только класс Book. Конечно же, BookLocator можно реализовать несколькими разными способами. Так, можно использовать автора книги и ее название, чтобы найти информацию из объекта Book. Это всегда зависит от нашей задачи. Важно то, что при переезде библиотеки в другое помещение организация хранения книг, скорее всего, изменится, и библиотекарю придется искать книги в новой библиотеке, но при этом объект Book затронут не будет. Точно также, если мы позволим читателям просматривать только аннотации книг, закрыв доступ к их страницам – мы никак не повлияем ни на библиотекаря, ни на собственно процесс поиска полок, на которых находятся книги.

Однако если наша задача – исключить библиотекаря и разработать механизм самообслуживания в нашей библиотеке, то мы можем считать, что ПЕО был соблюден в нашем первом примере. Читатели в этом случае сами станут выступать в роли библиотекарей, и им придется идти искать книги самостоятельно, после чего подтверждать получение нужной книги в автоматизированной системе. Существует и такая возможность. Главное, что здесь нужно запомнить, - это то, что Вы всегда должны обдумывать свои задачи очень тщательно.

Выводы

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

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

Источник: code.tutsplus.com