CHAPTER 8 행동 디자인 패턴 - 2

[audxo112]

8.4 전략 패턴

코드에서 if-else 분기 판단문이나 switch-case 분기 판단문을 제거해야 하는 상황에는 어떤 것이 있는지 생각해보자

8.5 책임 연쇄 패턴

책임 연쇄 패턴을 사용하면 프레임워크 코드가 개방 폐쇄 원칙을 충족하도록 만들 수 있다. 새 핸들러가 추가될 때는 클라이언트 코드만 수정하면 되는데, 이때 클라이언트 코드도 개방 폐쇄 원칙을 만족시키기 위해, 코드를 수정하지 않고 새 핸들러를 추가 할 수 있는 방법이 있는지 생각해보자

8.6 상태 패턴

이번 절에서 살펴본 상태 패턴 기반의 코드에서 여전히 몇 가지 문제점이 있다. 예를 들어 모든 이벤트 함수가 상태 인터페이스에 정의되어 있기 때문에, 상태 클래스가 이러한 이벤트 중 일부를 지원할 필요가 없더라도, 모든 이벤트에 대응하는 함수를 구현해야 한다. 뿐만 아니라 상태 인터페이스에 이벤트를 추가하면 모든 상태 클래스가 그에 따라 수정되어야 한다. 이 문제를 어떤 식으로 해결할 수 있을지 생각해보자.

[audxo112]

8.4

단순히 if - else 나 switch-case (when) 과 같은 분기로 작성했을 때 가독성의 문제가 없다면 그대로 사용해도 무방해 보인다
조건에 따라 로직이 변경되는 경우에 사용하면 좋을 것 같다
hashMap 에서 key가 같은 데이터의 갯수에 따라 linked list 와 red black tree로 관리하는 것 처럼

8.5

클라이언트에 hock 이나 interceptor 를 추가한다
Retrofit 의 HttpClient 에 추가하는 것 처럼

8.6

상태 인터페이스를 상속 하는 BaseClass 를 만들어서 모든 이벤트를 구현해야 하는 문제는 해결할 수 있다
상속을 사용하면 좋은 상황에서는 쓰는 게 맞다 생각한다

[lee-ji-hoon]

8.4

개인적으로 when문으로 무조건 처리하는 것들은 enum 혹은 sealed 처럼 컴파일 단계에서 빼먹거나 하는 실수를 방지하게 해주는 경우 자주 쓰게 되고 그 외에는 거의 if else 문으로 처리하는거 같아

8.5

1. 핸들러 등록을 동적으로: 핸들러를 등록하는 메커니즘을 제공하는 HandlerRegistry를 사용
2. 의존성 주입 사용: 핸들러를 의존성 주입 통해 주입

8.6

이런 경우는 어쩔 수 없이 상속 이 최고로 보이며 이때 진짜로 공통된 기능 이며 절대로 불변한 로직인지를 잘 생각하고 Base에 추가를 해야 한다

[ldh019]

4. 전략 패턴

매우 복잡한 형태의 if-else 분기, switch-case 분기를 피하기 위해 사용

프레임워크를 확장하는 데 사용됨

1. 전략의 정의

전략 = 전략 인터페이스 + 구현하는 전략 클래스

구현을 다르게 해서 유연성을 확보함

2. 전략의 생성

생성 논리를 캡슐화

유형에 따라 생성 전략의 논리를 코드로 작성

3. 전략의 사용

실행 시간 역학을 통해 전략을 동적으로 결정

테이블 조회 방법을 사용함

사용하지 않으면 if-else가 남아있는 것 아닌가 하지만 해당 내용이 캡슐화 되어 내부에 들어가기 때문에 밖에서는 쉽게 쓸 수 있음

if-else switch-case 가 나쁜 코드가 아니다

너무 과하지 않게 적절히 사용하면 전혀 문제 없음

생각해보기

분기가 너무 많아서 코드를 이해하기 힘든 경우

조건이 너무 많아서 한번에 처리하기 힘든 경우

5. 책임 연쇄 패턴

재사용과 확장이라는 동일한 목적(템플릿 메서드, 전략 패턴)

프레임워크 코드를 수정하지 않고도 기능을 확장시킬 수 있도록 함

플러그인, 필터, 인터셉터를 개발하기 위해 많이 사용됨

여러 수신 객체가 차례로 요청을 처리하는 방식

1. 링크드리스트

요청을 처리할 수 있으면 전달 중단, 불가능하면 successor.handle() 함수를 호출해 다음으로 전달

HandlerChain 에 링크드 리스트로 여러 개의 프로세서를 관리

2. 배열

HandlerChain을 배열로 구현

생각해보기

클라이언트도 프레임워크처럼 구조를 만들어놓고 인터셉터 같은거 만들면 되지 않을까?

6. 상태 패턴

일반적으로 잘 사용되는 패턴은 아님

상태 머신을 구현하는 데 사용, 보통 게임이나 워크플로 엔진 같은 시스템 개발에 사용

FSM 구현을 할때처럼 분기, 전이 테이블을 사용할 수도 있지만 상태 패턴을 쓸 수 있음

생각해보기

이전에도 여러번 나왔으니까 자주 쓰는 상속…을 사용해야겠지?

인터페이스처럼 모두 같이 상속받는 베이스 클래스를 만들면 될거 같은데

대신 베이스 클래스니까 설계에 신경쓰고 만들기~