1. 의도
- 메시지를 보내는 객체와 이를 받아 처리하는 객체들 간의 결합도를 없애기 위한 패턴입니다.
- 하나의 요청에 대한 처리가 반드시 한 객체에서만 되지 않고, 여러 객체에게 그 처리 기회를 주려는 것입니다.
2. 동기
3. 활용성
- 하나 이상의 객체가 요청을 처리해야 하고, 그 요청 처리자 중 어떤 것이 선행자(priori)인지 모를 때 - 처리자가 자동으로 확정되어야 합니다.
- 메시지를 받을 객체를 명시하지 않은 채 여러 객체 중 하나에게 처리를 요청하고 싶을 때
- 요청을 처리할 수 있는 객체 집합이 동적으로 정의 되어야 할 때
4. 구조
5. 참여자
- Handler :
- 요청을 처리하는 인터페이스를 정의합니다.
- 후속 처리자와 연결을 구현합니다.
- 즉, 연결 고리에 연결된 다음 객체에게 다시 메시지를 보냅니다.
- ConcreteHandler
- 책임져야 할 행동이 있다면 → 스스로 요청을 처리하여 후속 처리자에 접근할 수 있습니다.
- 즉, 자신이 처리할 행동이 있으면 처리하고, 그렇지 않으면 후속 처리자에 다시 처리를 요청합니다.
- Client
- ConcreteHandler 객체에게 필요한 요청을 보냅니다.
6. 협력 방법
- 사용자는 처리를 요청합니다
- 이 처리 요청은 실제로 그 요청을 받을 책임이 있는 ConcreteHandler 객체를 만날 때가지 정의된 연결 고리를 따라서 계속 전달됩니다.
7. 결과
- 객체간의 행동적 결합도가 적어집니다.
- 다른 객체가 어떻게 요청을 처리하는지 몰라도 됩니다.
- 단지 요청을 보내는 객체는 이 메시지가 적절하게 처리될 것이라는 것만 확신하면 됩니다.
- 메시지를 보내는 측이나 받는 측 모두 서로를 모르고, 또 연결된 객체들조차도 그 연결 구조가 어떻게 되는지 모릅니다.
- 결과적으로 이 패턴은 객체들 간의 상호작용을 단순화시킵니다.
- 객체가 관련된 모든 후보 객체들을 다 알 필요 없이 자신은 단순하게 자신과 연결된 단 하나의 후보 객체만 알면 되는 것입니다.
- 객체에게 책임을 할당하는 데 유연성을 높일 수 있습니다. 객체의 책임을 여러 객체에게 분산시킬 수 있으므로 런타임에 객체 연결 고리를 변경하거나 추가하여 책임을 변경하거나 확장할 수 있습니다.
- 메시지 수신이 보장되지는 않습니다.
- 어떤 객체가 이 처리에 대한 수신을 담당한다는 것을 명시하지 않으므로 요청이 처리된다는 보장은 없습니다.
- 만약 객체들 간의 연결 고리가 잘 정의되지 않았다면 → 요청은 처리되지 못한 채로 버려질 수 있습니다.
8. 구현
- 후속 처리자들의 연결 고리 구현하기
- 후속 처리자 연결하기
- 처리 요청의 표현부를 정의합니다.
- https://github.com/thekim123/gof-design-pattern-study/tree/main/src/com/thekim12
안녕하세요