일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 바운디드컨텍스트
- Kotlin
- zuul
- 신입
- springcloud
- MSA
- mongo
- Redis
- spring scheduler
- 반버논
- ddd
- IDDD
- webframework
- kakao
- spring-web
- ifkakao
- Spring
- 개발자
- Pay
- Conference
- springboot
- spring caching
- springboot3
- docker
- spring6
- java17
- 애그리거트
- armeria
- 값객체
- MongoDB
- Today
- Total
Easy Understanding
웹 백엔드 관점으로 본 디자인 패턴 정리(1) - 디자인 패턴의 분류와 문법 본문
헤드퍼스트 디자인 패턴에서는 다음과 같은 13가지 패턴을 다루고 있다.
1. 전략 패턴
2. 옵저버 패턴
3. 데코레이터 패턴
4. 팩토리 패턴(팩토리 메서드, 추상 팩토리)
5. 싱글턴 패턴
6. 커맨드 패턴
7. 어댑터 패턴
8. 파사드 패턴
9. 템플릿 메서드 패턴
10. 반복자 패턴
11. 컴포지트 패턴
12. 상태 패턴
13. 프록시 패턴
디자인 패턴은 이외에도 다양하며, 다음의 링크에서 대부분의 패턴들을 확인할 수가 있다.
해당 링크가 가장 잘 정리되어 있는 것 같아서 종종 참고하고는 한다.
https://refactoring.guru/design-patterns/catalog
디자인 패턴은 크게 다음과 같이 세 가지로 분류할 수 있다.
생성: 객체의 생성과 관련된 패턴(싱글턴, 팩토리, 빌더 등)
행동: 객체들을 어떤 식으로 구성할건지와 관련된 패턴(전략, 상태, 옵저버, 반복자 등)
구조: 행위를 어떻게 처리할 것인지와 관련된 패턴(데코레이터, 컴포지트, 프록시 등)
이러한 구조가 실제 디자인 패턴을 도입하는 데에는 솔직히 도움은 하나도 안 된다고 보면 된다.
디자인 패턴의 적용은 특정 상황에 마주쳤을 때에 대한 해결책이기 때문에 이런 식으로 정리하는 건 딱히 의미가 없다.
그럼에도 분류가 좋은 이유는 이렇게 정리해두면 기억이 잘 되고,
면접 때 멋들어지게 말하기 좋은 듯하다.
다양한 패턴들을 분류함으로서 뭔가 체계적으로 정리되는 느낌이 있어서 난 좋아하기는 한다.
디자인 패턴을 기억하기에는 두 가지 키워드를 통해서 기억하는 것이 좋다.
바로 '상속'과 '컴포지션' 이다.
다수의 디자인패턴들이 이 두 가지 방법을 이용해서 더 효율적인 구조를 만들어내곤 한다.
어떤 패턴은 상속만을 통해서 이루어지기도 하며,
어떤 패턴은 컴포지션을 이용해서 이루어지기도 한다.
어떤 패턴은 두 가지를 동시에 사용하기도 한다.
이건 각 패턴을 정리할 때마다 강조해볼 예정이다.
상속이야 익숙할 것이고 컴포지션만 간단하게 언급하고 넘어가겠다.
어떤 클래스의 기능을 다른 클래스에서 사용하는 방법으로는 보통 상속이 있는데,
상속은 어떤 클래스의 자식 클래스가 되기를 자청함으로 만들어진다.
저는 당신의 자식이 되겠습니다! 와 같은 느낌이다.
class Parent {}
class Child extends Parent {}
이렇게 상속으로 구성하게 되면 Child는 Parent의 메서드들을 이어받아 사용할 수 있게 된다.
하지만 이러면 부모의 영향력이 자식에게 고스란히 전달된다.
부모님의 행동을 거부하기가 어렵다.
하지만 컴포지션은 부모의 행위를 내가 골라서 사용할 수 있다.
아니 컴포지션은 애초에 부모라고 생각도 안할거다.
class Unknown { ... }
class Me {
private Unknown a;
public Me(Unknown a){
this.a = a;
}
public void doMyWay(){
a.doSomething();
}
}
위의 코드에서 나(Me)는 모르는 아저씨(Unknown)의 코드를 생성자 등을 통해서 가져와서 사용하기만 한다.
이러면 부모의 영향력에서 자유롭고 뭔가 좀 더 유연한 방식으로 코드를 구성할 수 있다.
메서드 오버라이딩 따위는 할 필요도 없게 된다.
그리고 아저씨의 모든 메서드를 사용할 필요도 없고 내가 필요한 것만 사용하면 된다.
이런게 컴포지션의 힘이고 많은 디자인 패턴들에서 사용하게 될 것이다.
참고로 이펙티브 자바 책에서도 '상속보다는 컴포지션을 사용하라'라는 장이 있으니 참고하면 좋다.
디자인 패턴과 친해지려면 컴포지션의 장점을 알고 익숙해지는 것이 좋다.
'Study' 카테고리의 다른 글
웹 백엔드 관점으로 본 디자인 패턴 정리(3) - 옵저버 패턴(Observer Pattern) (0) | 2022.05.06 |
---|---|
웹 백엔드 관점으로 본 디자인 패턴 정리(2) - 전략 패턴(Strategy Pattern) (0) | 2022.05.05 |
DDD를 적용한 간단한 결제 컨텍스트 개발해보기(with CQRS) (0) | 2022.04.03 |
(5) DDD와 아키텍처 - Layered, Hexagonal, CQRS, Event-Sourcing (0) | 2022.03.06 |
(4) DDD의 서비스/팩토리/패키지 - 코드를 작성하는 세부 방법들 (0) | 2022.03.02 |