Цепочка обязанностей на Golang

Паттерны проектирования / Поведенческие паттерны

import (
    "fmt"
)

//Rescuer is Handler
type Rescuer interface {
    Help(code int)
}

//chain keeps the next Handler and the code
//of the request that the Handler takes
type chain struct {
    next Rescuer
    code int
}

//handle is HandleRequest()
func (c chain) handle(code int, toHelp func()) {
    if c.code == code {
        toHelp()
    } else if c.next != nil {
        c.next.Help(code)
    }
}

//Firefighter is ConcreteHandler
type Firefighter struct {
    chain
}

func (f Firefighter) toHelp() {
    fmt.Println("call firefighters")
}

//Help passes the request to the chain
func (f Firefighter) Help(code int) {
    f.handle(code, f.toHelp)
}

//Police is ConcreteHandler
type Police struct {
    chain
}

func (p Police) toHelp() {
    fmt.Println("call the police")
}

//Help passes the request to the chain
func (p Police) Help(code int) {
    p.handle(code, p.toHelp)
}

//Ambulance is ConcreteHandler
type Ambulance struct {
    chain
}

func (a Ambulance) toHelp() {
    fmt.Println("call an ambulance")
}

//Help passes the request to the chain
func (a Ambulance) Help(code int) {
    a.handle(code, a.toHelp)
}

//Client
ambulance := Ambulance{chain{nil, 3}}
police := Police{chain{ambulance, 2}}
firefighter := Firefighter{chain{police, 1}}
firefighter.Help(1)
//printed: call firefighters
firefighter.Help(2)
//printed: call the police
firefighter.Help(3)
//printed: call an ambulance

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

Задача. В службу поддержки приходят запросы разного масштаба. Мелкий идёт к помощнику, покрупнее - к менеджеру, совсем крупный - к директору. Если бы код, который отправляет запрос, сам выбирал получателя, ему пришлось бы знать каждого получателя и каждое правило. Каждый новый получатель требовал бы правки в отправителе.

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

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

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

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