본문 바로가기

Design/Design Pattern

[Design Pattern] Chain of Responsibility Pattern

이번 장에서는 연쇄 사슬(Chain of Responsibility) 패턴에 대해서 알아보도록 한다.
샘플 코드는 여기 (링크) 프로젝트의 테스트 코드로 정리해두었다.


책임 연쇄 패턴이란?
위키백과에 따른 정의는 아래와 같다.

명령 객체와 일련의 처리 객체를 포함하는 디자인 패턴.
각각의 처리 객체는 명령 객체를 처리할 수 있는 연산의 집합이고, 체인 안의 처리 객체가 처리할 수 없는 명령은 다음 처리 객체로 넘겨진다.

쉽게 말하면 고객의 요청이 있고 이 요청을 처리 가능할 수도 있는 객체들이 있다고 가정할 때
고객이 객체를 지정해서 요청을 하더라도 지정받은 객체가 처리하지 못하는 경우 다음 객체에게 요청을 전달하여 처리하게 하는 디자인 패턴이다.

필자는 책임 연쇄 패턴을 데이터베이스에 적용할 예정이다.
WritableDB(CRUD 처리가능)와 ReadOnlyDB(R만 처리가능)를 생성하고 둘을 체이닝하여 책임이 연쇄적으로 전달되도록 하겠다.


GoF Design Pattern에 따르만 아래와 같은 Class Diagram이 그려진다.

Handler: Client의 요청을 처리하는 추상 클래스

ConcreteHandler1, ConcreteHandler2: Client의 요청을 처리하는 구현체. 이들은 Client의 요청을 처리할 수도 못할 수도 있다.

위의 그림을 데이터베이스에 접목시키면 아래와 같은 Class Diagram이 그려진다.

MariaDB라는 추상 클래스가 있고
이를 확장(상속)한 WritableDB는 바쁘지 않을 때 CRUD 처리가 가능하다.
ReadOnlyDB또한 MariaDB를 확장하고 있으며 바쁘지 않을 때 R 처리가 가능하다.


코드를 보면서 하나씩 살펴보도록 한다.

Query Class
Client가 생성할 요청을 만들어낼 클래스.
Query가 어떠한 타입의 Query인지를 나타내는 QueryType을 가지고 있으며 실행될 Query도 가지고 있다.

MariaDB Class
Client의 요청할 객체들의 상위 추상 클래스.
이름을 가지고 있으며 자신이 처리하지 못할 경우 대신 처리할 객체(nextMariaDB)를 가지고 있다.
다음 객체에게 전달하는 부분은 process 메서드에 정의되어 있으며 모든 객체를 통해도 처리하지 못하는 경우 "처리가능한 DB 없음" 이라는 문구를 출력한다.
isBusy() 메서드는 DB가 바쁜 경우 다음 DB로 전달하는 상황을 만들기 위해서 임의로 DB의 상태를 바쁘게 만드는 메서드다.

ReadOnlyMariaDB Class
MariaDB의 구현체로 DB가 바쁘지 않고 SELECT Query라면 요청을 처리할 수 있다.

WritableMariaDB Class
MariaDB의 구현체로 DB가 바쁘지 않다면 모든 타입의 Query를 처리할 수 있다.

Client Class
MariaDB 구현체를 생성하고 이들을 연결하는 역할을 한다.
Query(요청)를 생성하고 MariaDB의 구현체에게 전달한다.

코드를 실행한 결과는 아래와 같다.


지금까지 읽기만 가능한 DB와 모든 요청을 처리할 수 있는 DB를 주제로 책임 연쇄 패턴에 대해서 알아보았다.

'Design > Design Pattern' 카테고리의 다른 글

[Design Pattern] Observer Pattern  (0) 2022.02.02
[Design Pattern] Facade Pattern  (0) 2022.02.02
[Design Pattern] Visitor Pattern  (0) 2022.02.02
[Design Pattern] Decorator Pattern  (0) 2022.02.02
[Design Pattern] Composite Pattern  (0) 2022.02.02