# 책임 연쇄 패턴?

클라이언트로 부터 연속적인 핸들러(Handler)를 따라 요청을 전달 하도록 하는 행동 디자인 패턴이다. 요청을 받으면 핸들러는 요청을 처리하거나 다음 핸들러로 요청을 전달한다. 기본적으로 linked list와 비슷하다. 하나의 핸들러는 다음 핸들러의 정보를 가지고 있고 그 다음 핸들러는 또 다음 핸들러의 정보를 가지고 있다. 핸들러에서 요청을 받게 되면 해당 요청을 처리 할 수 있는지 판단을 한 후에, 처리가 가능하다면 해당 핸들러에서 문제를 처리하고 불가능하다고 판단하게 되면 다음 핸들러로 넘기는 과정을 진행한다.

## 그렇다면 Handler라는건 뭐냐?

요청을 처리하기 위한 객체들

## 예제 코드개념

// 정비사의 경험에 따라 가능한 기술이 다르다. 정비사를 OilChangeOnly, Junior, Apprentice, MasterMechanic 4가지 기술 수준으로 분류할 것이다. 모든 정비사들은 위의 네가지 값중 하나의 기술 수준을 할당받는다. 또한 모든 기술 수준은 한 단계 높은 기술 수준에 대한 참조값을 갖게 된다. 그리고 필요한 최소 기술 수준을 포함한 수행하고자 하는 일련의 작업을 정의한 다음 가상의 상점을 정의하고 해당 작업들을 가장 첫 번째(가장 낮은 기술 수준)에게 전달한다.기술력이 부족한 정비사부터 기술력이 가장 좋은 정비사 까지 일을 전파시키기 위해서. 그렇게 한다면 기술력이 좋은 정비사는 본인의 일도 하면서 기술력이 않좋은 정비사들을 케어 할 수 있다. 이후 각 기술 수준을 거쳐 작업을 수행하는 데 필요한 최소한의 기술을 갖춘 정비사를 찾게 된다.

## 그러면 이걸 왜 쓰는데?

요청을 보내는 객체와 이를 처리하는 객체간의 결합도를 느슨하게 하는 장점이 있다. 객체들은 요청을 처리할 것인지 넘길 것인지만 판단하면 되고, 체인의 다른 객체들이 뭘 하는지 알 필요가 없다. 물론 이건 클라이언트도 몰라도 된다.

Single Responsibility Principle(단일 책임 원칙)을 지킬 수 있다. 작업을 수행하는 클래스, 작업을 호출하는 클래스를 분리할 수 있다.

Open, Closed Principle(개방/폐쇄 원칙)을 지킬 수 있다. 기존 클라이언트의 코드를 바꾸지 않고 새로운 핸들러를 앱에 추가할 수 있다.

## 단점은?

처리되지 않는 요청이 있을 수 있지만, 요청할 때는 이걸 알 수 없다. 체인의 끝까지 가야 알 수 있기 때문

체인을 잘 못 만들 경우 사이클이 발생할 수 있다.

https://icksw.tistory.com/250
https://github.com/kingreza/Swift-Chain-Of-Responsibility