Цепочка обязанностей - паттерн поведения, выстраивающий объекты составных частей приложения связанными между собой по цепочке, для передачи запроса на обработку от более низких, детализированных слоев системы к более высоким глобальным. codelab.ru codelab.ru оригинал источник

1. Handler (HelpHandler) – обработчик.
   Определяет интерфейс для обработки запросов.
   Реализует связь с преемником (необязательно). оригинал codelab.ru источник codelab.ru
2. ConcreteHandler (PrintButton, PrintDialog) - конкретный обработчик.
   Обрабатывает запрос, за который отвечает.
   Имеет доступ к своему преемнику.
   Если ConcreteHandler способен обработать запрос, то так и делает, если не может, то направляет его - его своему преемнику вверх по цепочке. оригинал codelab.ru источник codelab.ru
3. Client – клиент.
   Отправляет запрос некоторому объекту ConcreteHandler в цепочке. оригинал codelab.ru источник codelab.ru

1. Реализация цепочки преемников.
   Есть два способа реализовать такую цепочку: определить новые связи (обычно это делается в классе Handler, но можно и в ConcreteHandler), либо использовать существующие.
   До сих пор в наших примерах определялись новые связи, однако можно воспользоваться уже имеющимися ссылками на объекты для формирования цепочки преемников. Например, ссылка на родителя в иерархии «часть-целое» (паттерн компоновщик) может заодно определять и преемника «части». В структуре виджетов такие связи тоже могут существовать. В разделе, посвященном паттерну компоновщик, ссылки на родителей обсуждаются более подробно.
   Существующие связи можно использовать, когда они уже поддерживают нужную цепочку. Тогда мы избежим явного определения новых связей и сэкономим память. Но если структура не отражает устройства цепочки обязанностей, то уйти от определения избыточных связей не удастся. codelab.ru codelab.ru оригинал источник
2. Соединение преемников.
   Если готовых ссылок, пригодных для определения цепочки, нет, то их придется ввести. В таком случае класс Handler не только определяет интерфейс запросов, но еще и хранит ссылку на преемника. Следовательно у обработчика появляется возможность определить реализацию операции HandleRequest по умолчанию - перенаправление запроса преемнику (если таковой существует). Если подкласс ConcreteHandler не заинтересован в запросе, то ему и не надо замещать эту операцию, поскольку по умолчанию запрос как раз и отправляется дальше. Вот пример базового класса HelpHandler, в котором хранится указатель на преемника:
    Базовый ConcreteHandler c ссылкой на приемника [java]  ссылка
   

   package chainOfResponsibility;
    
   public class HelpHandler {
   	HelpHandler successor;
    
   	public HelpHandler(HelpHandler successor) {
   		super();
   		this.successor = successor;
   	}
    
   	public void HandleHelp() {
   		if (successor != null) {
   			successor.HandleHelp();
   		}
   	}
   }

   package chainOfResponsibility; public class HelpHandler { HelpHandler successor; public HelpHandler(HelpHandler successor) { super(); this.successor = successor; } public void HandleHelp() { if (successor != null) { successor.HandleHelp(); } } } оригинал codelab.ru источник codelab.ru
3. Представление запросов.
   Представлять запросы можно по-разному. В простейшей форме, например в случае класса HandleHelp, запрос жестко кодируется как вызов соответствующего дополнительного метода этого класса. Это удобно и безопасно, но переадресовывать тогда можно только фиксированный набор запросов, для которых в классе Handler определены специальные методы.
   Альтернатива - использовать единую функцию-обработчик, которой передается код запроса (скажем, целое число или строка). Так можно поддержать заранее неизвестное число запросов. Единственное требование состоит в том, что отправитель и получатель должны договориться о способе кодирования запроса.
   Это более гибкий подход, но при реализации нужно использовать условные операторы для распределения запросов по коду их обработки. Кроме того, не существует безопасного с точки зрения типов способа передачи параметров, поэтому упаковывать и распаковывать их приходится вручную. Очевидно, что это не так безопасно, как прямой вызов операции.
   Чтобы решить проблему передачи параметров, допустимо использовать отдельные объекты-запросы, в которых инкапсулированы параметры запроса. Т.е. специальный класс Request, например, может представлять некоторые запросы явно, а их новые типы описываются в подклассах. Подкласс может определить другие параметры. Обработчик должен иметь информацию о типе запроса (какой именно подкласс Request используется), чтобы разобрать эти параметры.
   Для идентификации запроса в классе Request можно определить функцию доступа, которая возвращает идентификатор класса. Вместо этого получатель мог бы воспользоваться информацией о типе, доступной во время выполнения, если язык программирования поддерживает такую возможность (в случае Java-ы для этих целей можно б было использовать результат выполнения .getClass().getName()).
   Приведем пример функции диспетчеризации, в которой используются объекты для идентификации запросов. Операция GetKind, указанная в базовом классе Request, определяет вид запроса:
   
    единая функция переадресации запросов [java]  ссылка
   

   package chainOfResponsibility;
    
   public class Handler {
    
   	public void HandleRequest(Request req) {
   		switch (req.GetKind()) {
   			case Request.HELP:
   				HandleHelp(req);
   				break;
   			case Request.PRINT:
   				HandlePrint(req);
   				break;
   			default:
   				// ...
   				break;
   		}
   	}
    
   	protected void HandlePrint(Request req) {
   		// ...		
   	}
    
   	protected void HandleHelp(Request req) {
   		// ...	}
   }

   package chainOfResponsibility; public class Handler { public void HandleRequest(Request req) { switch (req.GetKind()) { case Request.HELP: HandleHelp(req); break; case Request.PRINT: HandlePrint(req); break; default: // ... break; } } protected void HandlePrint(Request req) { // ... } protected void HandleHelp(Request req) { // ... } }
   И подклассы могут расширить схему диспетчеризации, переопределив операцию HandleRequest. Подкласс обрабатывает лишь те запросы, в которых заинтересован, а остальные отправляет родительскому классу. В этом случае подкласс именно расширяет, а не замещает операцию HandleRequest. Например, подкласс ExtendedHandler расширяет операцию HandleRequest, определенную в классе Handler, следующим образом:
   
    расширение схемы диспетчеризации подклассами [java]  ссылка
   

   package chainOfResponsibility;
    
   public class ExtendedHandler extends Handler {
    
   	@Override
   	public void HandleRequest(Request req) {
   		switch (req.GetKind()) {
   			case Request.PREVIEW:
   				HandlerPreview(req);
   				break;
   			default:
   				super.HandleHelp(req);
   				break;
   		}
   	}
    
   	protected void HandlerPreview(Request req) {
   		// ...
    
   	}
   }

   package chainOfResponsibility; public class ExtendedHandler extends Handler { @Override public void HandleRequest(Request req) { switch (req.GetKind()) { case Request.PREVIEW: HandlerPreview(req); break; default: super.HandleHelp(req); break; } } protected void HandlerPreview(Request req) { // ... } } оригинал codelab.ru codelab.ru источник
4. Автоматическое перенаправление запросов специфическими средствами языка.
   Такими как, например, анонимная функция __call() в PHP, начиная с 5-ой версии, автоматически вызываемая средой языка если происходит попытка вызвать у объекта несуществующий в нем метод.
   В Smalltalk для этих целей используется механизм doesNotUnderstand.
   В любом случае мы получаем функционал, при котором сообщения, не имеющие соответствующих методов, перехватываются реализацией __call(), doesNotUnderstand, которая может быть замещена для перенаправления сообщения объекту-преемнику. Поэтому осуществлять перенаправление вручную уже не придется.
   Класс обрабатывает только запросы, в которых заинтересован, и ожидает, что механизм doesNotUnderstand()/__call() выполнит обработку по-умолчанию для всех остальных запросов. codelab.ru оригинал источник codelab.ru

1. Ослабление связанности.
   Этот паттерн освобождает объект от необходимости «знать», кто конкретно обработает его запрос. Отправителю и получателю ничего неизвестно друг о друге, а включенному в цепочку объекту - о структуре цепочки.
   Таким образом, цепочка обязанностей помогает упростить взаимосвязи между объектами. Вместо того чтобы хранить ссылки на все объекты, которые могут стать получателями запроса, объект должен располагать информацией лишь о своем ближайшем преемнике. источник оригинал codelab.ru codelab.ru
2. Дополнительная гибкость при распределении обязанностей между объектами.
   Цепочка обязанностей позволяет повысить гибкость распределения обязанностей между объектами. Добавить или изменить обязанности по обработке запроса можно, включив в цепочку новых участников или изменив ее каким-то другим образом. Этот подход можно сочетать со статическим порождением подклассов для создания специализированных обработчиков. codelab.ru источник codelab.ru оригинал
3. Получение не гарантировано.
   Поскольку у запроса нет явного получателя, то нет и гарантий, что он вообще будет обработан: он может достичь конца цепочки и пропасть. Необработанным запрос может оказаться и в случае неправильной конфигурации цепочки. оригинал codelab.ru codelab.ru источник

У новости есть заголовок, текст и собственно дата новости: News. codelab.ru оригинал источник codelab.ru

Новости хранятся в базе данных и для того, чтобы их оттуда доставать любые модули, совершенно ничего не знающие ни о каких базах, определена сущность DAO (Data Access Object), у которой имеются 2 необходимых метода: достать одну последнюю новость или список всех новостей: DAO_I. codelab.ru источник codelab.ru оригинал

  codelab.ru codelab.ru оригинал источник