designPattern

특정 문맥에서 공통적으로 발생하는 문제에 대한 재사용 가능한 해결책
SW를 디자인할 때 공통적이고 반복된 문제들을 해결하는데 쓰이는 형식화된 좋은 관행!
항상 적용할 필요는 없고 사례를 참고하는 게 좋다.
- 모범사례를 통해 시야확장
- 유연한 설계를 지닌 객체지향의 장점
- 디자인 패턴의 이름으로된 클래스들이 이미 다수 존재한다.
  - 코드를 이해하기 위해 필요

GoF(gang of four) 디자인 패턴 구분

생성패턴
- 객체 생성 혹은 조합에 관한 패턴
구조패턴
- 객체를 조합해 더 큰 구조를 만드는 패턴
- 새로운 기능을 추가하는데 관련된 패턴
행위패턴
- 객체 사이 책임분배나 커뮤니케이션에 관한 패턴
- 단일 객체가 처리해야될 일을 여러 객체로 나눌 때 어떻게 배분하면서 결합도를 낮출지

Singleton (생성패턴)

클래스의 인스턴스가 1개임을 보장하고 싶다.
인스턴스 생성을 제어할수 있어야함.
1개뿐인 인스턴스에 쉽게 접근할 수 있어야함(글로벌 객체)
지연로딩 전략 가능

Builder (생성패턴)

복잡한 객체의 생성방법과 표현방법을 분리해야 함.
생성방법과 구성방법 모두 캡슐화 해야 함.
객체 생성에 필요한 파라미터가 너무 많아 생성자 오버로딩이 과할 때 유용
자바에선 named parameter 기능이 없어 lombok의 빌더패턴이 자주 쓰인다

Factory Method (생성 패턴)

복잡한 객체 생성을 캡슐화 해야한다.
생성은 다른 클래스에게 위임하려한다.
- 빌더패턴도 실제 객체의 생성은 빌더에 위임했다.
어떤 인스턴스를 만들어야 할지 알 수 없음.
- 빌더의 경우 1:1 매핑이지만 팩토리는 여러가지를 만들 수 있다.

팩토리 구현 방식

하나의 팩토리에서 타입을 받아 각각의 구현체를 얻는 방식
팩토리 자체가 여러 개로 나뉘어 타입을 주지 않고도 원하는 구현체를 제공해주는 팩토리방식
- 각각 장단이 있지만 스프링에서는 빈 DI를 사용하기 때문에 이 방식이 좀 더 유용할 수 있다.

Adaptor (구조 패턴)

서로 다른 시스템, 인터페이스 등을 함께 동작(연결)하고자 할 때 ( 실제 어댑터의 역할 ) 기대하는 다른 인터페이스로 변환하는 패턴

해결할 수 있는 문제

클라이언트에 필요한 인터페이스가 없는 클래스를 재사용할 수 있다.
호환되지 않는 인터페이스가 있는 클래스를 작동시킬 수 있다.
클래스에 대한 대체 인터페이스를 제공해줄 수 있다.

핵심 아이디어

adapter(이미 존재하는) 클래스의 인터페이스를 변경하지 않고 별도의 작업을 수행하는 것

Facade {건물의 전면 또는 외부를 의미하는 프랑스 용어에서 차용.} (구조 패턴)

복잡한 서브시스템의 인터페이스를 단순하게 구성하고자 할 때
시스템간 결합도를 줄이고자 할 때
서브시스템을 계층화 시키고 싶을 때
간단하게 정리하면, 복잡한 로직을 캡슐화하여 간단한 인터페이스로 제공해 줌으로써 객체를 사용하는 클라이언트 단에서는 뒤의 복잡한 로직을 알지 않아도 된다.

Decorator (구조 패턴)

기존 객체를 수정 없이 새로운 책임을 추가하고 싶을 때
객체를 사용하는 클라이언트에 코드의 변경 없이 책임을 추가할 수 있다.
단일 책임 원칙 을 준수하는데 유용하다.

원래 클래스를 감싸는 새로운 Decorator 클래스를 설계함으로써 기존 클래스에 변경 없이 기능을 확장(장식,decorate)할 수 있다. 이 패턴은 재정의된 메서드에 새 기능을 추가할 때마다 여러 데코레이터를 서로 쌓을 수 있도록 설계되어서 유연한 확장이 가능하다.

Proxy (구조 패턴)

다른 항목에 대한 인터페이스 역할을 하는 클래스이다.

객체에 접근을 제어하고 싶을 때 사용할 수 있다.

객체를 실제 사용하기 전까지 초기화를 미루고 싶을 때 ex) JPA ENTITY LAZY 로딩 시

개체에 액세스할 때 추가 기능을 제공해야 합니다.

예를 들어 민감한 개체에 액세스할 때 클라이언트에 필요한 액세스 권한이 있는지 확인할 수 있어야 한다.

데코레이터 패턴과 유사하지만 데코레이터 패턴은 새 기능을 추가하는데 초점이 있고 프록시 패턴은 객체의 액세스 제어에 초점이 있다.

Strategy (행동 패턴)

실행 중에 알고리즘을 선택할 수 있게 하는 행위 소프트웨어 디자인 패턴이다.

클라이언트의 코드 변경 없이 독립적으로 문제 해결 전략을 바꾸고 싶을 때
다양한 문제해결 방법을 제공해야 할 때
특정한 계열의 알고리즘들을 정의하고 각 알고리즘을 캡슐화하여 이 알고리즘들을 해당 계열 안에서 상호 교체가 가능하게 만든다.

Template method (행동 패턴)

기능의 뼈대(템플릿)과 실제 구현을 분리하는 패턴이다.

구체적인 처리방법은 하위 클래스로 위임하고자 할 때

전략패턴과의 비교

전략패턴이 구체적인 구현내용을 숨기고 쉽게 교체할 수 있게 만드는데 목적이 있다면
템플릿 메서드 패턴은 기능(이미 기술된 상위로직)에서 특정 로직, 단계만 제어하고 싶을 때 사용한다.

단점

template 메서드 자체가 변경될 여지가 있으면 사용하면 안된다. 그렇기에 전략패턴과의 차이를 명확히 이해하고 사용해야 한다.
예를들어 전략패턴으로 구현을 했는데 중복되는 로직이 있어서 템플릿메서드 패턴으로 바꿨지만 알고보니 그쪽만의 flow 였고 다른 쪽을 사용할 때 다른 flow로 돌아갈 수 있다.
결론은 템플릿에 예외 케이스가 생길 수 있다면 사용하지 않는 것이 좋다.

Chain of Responsibility (행동 패턴)

메시지를 보내는 객체와 처리하는 객체를 분리하고 싶을 때
하나의 메시지를 여러 객체가 처리해야할 때
자료구조의 링크드리스트와 유사하다.
코드 수정 없이 handler 확장이 가능 (OCP)
명령을 내리는 객체와 수행하는 객체의 분리 (SRP)
자바의 try-catch 구문이 책임연쇄패턴으로 작성되어있다.
각 catch 구문들은 자기가 처리하거나, 다음 catch 구문으로 책임을 넘긴다.