일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- 백업
- auth methods
- secret engines
- REST API
- Secret Engine
- 인프라
- DATA 백업
- 시스템
- VIRT
- key/value
- 앤서블
- IAC
- 파일시스템
- 커널 파라미터
- 전체 백업
- Vault
- Role
- SSH OTP
- 구성관리
- 자동화
- 차분 백업
- hashicorp
- SHR
- kv
- devops
- 리눅스
- 통합 풀 백업
- vault agent
- 유닉스
- backend storage
- Today
- Total
클라우드 아카이브
[생성 패턴] Builder Pattern (빌더 패턴)이란? 본문
목표
- 생성 패턴이 무엇인지에 대해 간략하게 설명한 뒤에 빌더 패턴에 대해 알아보겠습니다.
생성 패턴이란?
디자인 패턴에 대해 기초를 닦을 수 있는 대표적인 사이트인 리팩토링 그루(링크)에서는 생성 패턴을 아래와 같이 설명하고 있습니다.
생성 패턴들은 기존 코드의 재활용과 유연성을 증가시키는 객체 생성 메커니즘들을 제공합니다.
즉 객체 생성 시 객체지향 개발 원칙인 SOLID를 최대한 준수할 수 있음과 동시에 다른 프로젝트 혹은 코드에서 Reusability(재활용성)를 높일 수 있도록 도와주는 디자인 패턴입니다.
Builder Pattern (빌더 패턴)
빌더 패턴은 객체를 단계 별로 생성할 수 있도록 해주는 생성 패턴입니다.
위 말만 봤을 때는 빌더 패턴이 도대체 무엇인지 이해가 안될 수 있습니다. 이해를 돕기 위해 하나의 문제를 가정해보겠습니다. 자동차를 만드는 공장에서는 아반떼, 쏘나타, 그랜저 등 다양한 차종을 양산하고 있습니다. 이 경우 자동차라는 단일 객체가 아닌 각 차종이 객체가 될 수 있는데요. 프레임, 엔진, 의자 종류이 다를 뿐인데 각 차종 별로 객체를 따로 생성 및 관리해주어야 합니다. 또한 사용자가 선택한 옵션에 따라 관리해주어야 하기 때문에 자동차를 중심으로 자식 클래스들의 계층구조가 점점 복잡해질 뿐만 아니라 객체 생성 코드가 못생겨질 수 있다는 문제점이 있습니다. 심지어 그랜저에만 가지고 있는 옵션이 있을 경우 개발자가 객체 생성 시점에서 해당 코드를 보고 햇갈릴 수도 있죠.
위 문제를 해결하기 위해 빌더 패턴을 사용할 수 있으며 해당 패턴은 자동차 클래스에서 객체 생성 코드를 추출하여 builder라는 별도의 객체들로 관리할 수 있도록 제안합니다.
builder에서 buildFrame(프레임 생성), buildEngine(엔진 부착), buildSeats(의자 부착) 등을 구현하고, 특정 차종에 대한 객체 생성 시 Builder 객체를 활용하면 되는 것입니다. 특히 모든 단계를 호출하는 것이 아닌 해당 자동차 차종을 제작하는데 필요한 단계들만 호출하면 됩니다. 혹자는 일부 자동차 차종에서 의자를 부착할 때 안마 기능이 부가적으로 들어가있는 등의 별도 구현이 필요할 수 있는데요. 이 경우 특수 Case를 전담하는 별도의 Builder 클래스를 구현하고 해당 Builder를 통해 특수 기능을 부여해주면 됩니다.
마무리
디자인 패턴 중 생성 패턴인 Builder Pattern(빌더 패턴)에 대해 알아보았습니다.
다음 포스팅에서는 실제 오픈 소스에서 해당 Builder Pattern을 어떻게 적용하여 구현했는지에 대해 작성하겠습니다.