[디자인 패턴] 코딩으로 학습하는 GoF의 디자인 패턴 - 3

https://www.inflearn.com/course/디자인-패턴

코딩으로 학습하는 GoF의 디자인 패턴 - 인프런 | 강의

 

책임 연쇄 패턴

패턴 소개

- abstract class를 상속하여 구현하며, 생성자에 상속타입의 필드를 두어 저장

- 장점

> OCP, SRP

- 단점

> 디버깅이 어렵다

 

자바와 스프링에서 찾아보는 패턴

- 필터와 인터셉터

- 스프링 시큐리티 필터
 > 거대한 필터 체인
 > 스프링 config에서 필터체인 설정을 바꿀수 있다.

 

커맨드 패턴

패턴 소개

- 요청을 캡슐화하여 호출자와 수신자를 분리하는 패턴

- 장점

 > undo 기능을 구현할 수 있다.

 

자바와 스프링에서 찾아보는 패턴

- 메서드 레퍼런스

- SimpleJdbcTemplate insert

 

인터프리터 패턴

패턴 소개

- 정규표현식 -> 인터프리터 패턴
- 요청을 캡슐화하여 호출자와 수신자를 분리하는 패턴

- 자주 등장하는 문제를 간단한 언어로 정의하고 재사용하는 패턴

- 트리구조를 사용 (AST)

- 컴포짓 패턴과 유사함

- 장점
 > 자주 등장하는 문제패턴을 언어와 문법으로 정의할 수 있다.

 > 기존 코드를 변경하지 않고 새로운 Expression을 추가할 수 있다.

- 단점

 > 복잡한 문법을 표현하려면 expression과 parser가 복잡해진다.

 

자바와 스프링에서 찾아보는 패턴

- 정규표현식, JVM 컴파일러

- SPEL

이터레이퍼 패턴

패턴 소개

- 집합 객체를 순회하는 패턴

- 집합 객체를 순회하는 클라이언트의 코드를 변경하지 않고, 다양한 순회방법을 제공할 수 있다.

- 장점

 > 집합 객체에 손쉽게 접근이 가능하다. (hasnext와 next만 알면 된다.)
- 단점

 > 이터레이터를 return 하는 코드를 만들어줘야한다.

 > 이터레이터를 만들어야 하는지 생각해봐야한다. ( 설계상 과연 정말 필요한가? )

 

자바와 스프링에서 찾아보는 패턴

- 이터레이터

- Enumeration
 -> 이터레이터로 대체됨
- STAX (Streaming API for XML )

 

중재자 패턴

패턴 소개

- 여러 객체들이 소통하는 방법을 캡슐화하는 패턴

- 여러 컴포넌트간의 결합도를 중재라를 통해 낮출 수 있다.

 -> 중재자 외에는 클라이언트를 자세히 알거나 의존하면 안된다.

- 장점

 > 컴포넌트 코드를 변경하지 않고, 새로운 중재자를 만들어 사용할 수 있다.

 > 각각의 컴포넌트 코드를 보다 간결하게 유지할 수 있다.

- 단점

 > 중재자 역할을 하는 클래스의 복잡도와 결합도가 커져서 변경하기 어렵다.

 

자바와 스프링에서 찾아보는 패턴

- ExcutorService, Excutor

- Dispathcer Sevlet

 

메멘토 패턴

패턴 소개

- 객체 내부의 상태를 밖으로 디테일하게 공개하지 않으면서 (캡슐화를 지키면서) 외부에 저장함

- 객체 상태를 외부에 저장했다가 해당상태로 다시 복구할 수 있다.

- 장점

 > OCP

 > 내부 필드값을 몰라도 된다.

 

자바와 스프링에서 찾아보는 패턴

- Date 클래스

- 직렬화, 역직렬화

 

옵저버 패턴

패턴 소개

- Pub-Sub 패턴 쉽게 구현 가능

- 다수의 객체가 특정 객체 상태 변화를 감지하고 알림을 받는 패턴

- 장점

 > 상태를 변경하는 객체 (Publisher)와 변경를 감지하는 객체 (Subscriber) 의 관계를 느슨하게 유지할 수 있다.

 > Subject의 상태 변경을 주기적으로 조회하지 않고 자동으로 감지할 수 있다.

 > 런타임에 옵저버를 추가하거나 제거할 수 있다.

- 단점

 > 복잡도가 증가한다.

 > 다수의 observer 객체를 등록 이후 해지하지 않는다면 Memory Leak이 발생할 수도 있다. 

  -> WeakReference 활용하여 해결하자

 

자바와 스프링에서 찾아보는 패턴

- Observer

 -> Property Change Listener

 -> Flow api

- ApplicationContext

 -> @EventListner

 

상태패턴

패턴 소개

- 상태에 따라 처리해야할 로직이 달라야함

- 객체 내부 상태 변경에 따라 객체 행동이 달라지는 패턴

- 상태에 특화된 행동들을 분리해 낼 수 있으며, 새로운 행동을 추가하더라도 다른 행동에 영향을 주지 않는다.

- 장점

 > 상태에 따른 여러가지 행동들이 개별 클래스로 옮겨져 관리할 수 있다.

 > 기존의 특정 상태에 따른 동작을 변경하지 않고 새로운 상태에 따른 동작을 추가할 수 있다.

 > 코드 복잡도를 줄일 수 있다.

 

전략패턴

패턴 소개

- 전략패턴은 어떤 일을 수행하는 알고리즘이 여러가지 일때, 추상화된 인터페이스를 사용하여 구조변경 없이 알고리즘을 바꿔 사용하는 패턴

- 여러 알고리즘을 캡슐화하고 상호 교환 가능하게 만드는 패턴

- 컨텍스트에서 사용할 알고리즘을 클라이언트가 선택한다.

 

장점

- 새로운 전략을 추가하더라도 기존 코드를 변경하지 않는다.

- 상속 대신 위임을 사용할 수 있다.

- 런타임에 전략을 변경할 수 있다.

 

단점

- 복잡도가 증가한다.

- 클라이언트 코드가 구체적인 전략을 알아야 한다. (의존성이 생김)

 

자바와 스프링에서 찾아보는 패턴

- Comparator

- ApplicationContext

 

템플릿 메소드 패턴

패턴 소개

- 알고리즘 구조를 서브 클래스가 확장할 수 있도록 템플릿으로 제공하는 방법

- 추상 클래스는 템플릿 제공하고 하위 클래스는 구체적인 알고리즘을 제공한다.

- 거의 비슷한데 중간에 몇줄만 다른 코드에 적용하기 좋음

 

+) 템플릿 콜백 패턴

- 콜백으로 상속 대신 위임을 사용하는 템플릿 패턴

- 상속 대신 익명 내부 클래스 또는 람다 표현식을 활용할 수 있다.

 

장점

- 템플릿 코드를 재사용하고 중복 코드를 줄일 수 있다.

- 템플릿 코드를 변경하지 않고 상속을 받아서 구체적인 알고리즘만 변경할 수 있다.

 

단점

- 리스코프 치환 원칙을 위반할 수도 있다.

- 알고리즘 구조가 복잡할 수록 템플릿을 유지하기 어려워진다.

 

자바와 스프링에서 찾아보는 패턴

- HttpServlet

- Websecurity init
- 템플릿 콜백 : Rest Template, JDBC Template

 

비지터 패턴

패턴 소개

- 기존 코드를 변경하지 않고 새로운 기능을 추가하는 패턴

- 더블 디스패치 를 활용할 수 있다.
>  디스패치란 어떤 메서드를 호출할 것인가 를 결정하는 과정을 말한다.

    즉 메서드의 의존성을 결정하는 과정이라 할 수 있다.

단점

- 코드 복잡도 증가

- 새로운 엘리먼트가 사라지거나 추가될때, 많은곳에 변화가 필요

 

자바와 스프링에서 찾아보는 패턴

- FileVisitor, SimpleFileVisitor

- AnnotationValueVisitor

- ElementVisitor

- BeanDefinitionVisitor