Today I Learned - Day 61 [디자인 패턴 - 2]

이번에도 찾아온 디자인 패턴 정리 시간이다.

금일에는 '생성'과 관련된 패턴을 정리해볼까 한다.

[참고 URL: https://refactoring.guru/ko]

디자인 패턴 - 1 : https://lsu0503.tistory.com/120

Today I Learned - Day 59 [디자인 패턴 - 1]

---

빌더

[참고 URL : https://refactoring.guru/ko/design-patterns/builder]

빌더라고 하면 개발자 입장에서는 코드를 Build하는 그것을 떠올릴 가능성이 높다고 생각한다.

사실, 코드에 Build라는 단어가 쓰인 이유가 같은 이유이긴 하나, 엄밀히 말하자면 그 Build는 아니고, 그냥 '건축가'로서의 Builder다.

이점을 유의하고 한번 살펴보자.

 

프로그래밍을 하다 보면 '초기 생성 시에 이래저래 설정을 해야하는 경우'가 더러 발생한다.

이를 모두 생성자에 박아넣으면 어떻게 될까.

분명 생성자인데 줄은 수십줄이 넘는다거나, 아마 글자는 흰색이고 배경은 검정색인 그 무언가가 될 것이다.

빌더 패턴은 이럴 때에 사용하는 패턴이다.

 

내용은 간단하다. '빌더' 클래스를 만들고, 그 조합으로 초기화하는 것.

즉, 초기화를 자기 자신이 수행하는 것이 아니라, 초기화를 담당하는 외부 클래스를 두는 것.

복잡한 부분을 따로 떼서 정리하자는 것이다. 일종의 포스트잇 같은 느낌.

 

사실, 이를 응용하면 '템플릿을 이용한 오브젝트 생성'도 가능하다. 즉, 브릿지 패턴의 내용도 일부 포함한다고 볼 수 있다.

 

추가로, 다른 클래스에서 '함수 하나'로 초기화를 할 수 있게끔 초기화 함수들을 규합하는 디렉터 클래스를 둘 수도 있다.

---

추상 팩토리

[참고 URL : https://refactoring.guru/ko/design-patterns/abstract-factory]

자, 물건을 만든다고 생각 해 보자. 하나의 물건을 만드는 데 설정해야 하는 분류 정보는 다음과 같다.

• 물건의 색상: 빨강, 주황, 노랑, 초록, 파랑, 남색, 보라색, 흰색, 검정색
• 물건의 형태: 구체, 박스, 삼각뿔, 모래시계, 원기둥
• 물건의 재질: 플라스틱, 유리, 금속

이러한 물건을 만든다고 할 때, 실제 공장에서는 어떤 과정을 거칠까?

[단, 물건의 재질에 관계없이 '주형' 방식으로 제작하며, 색상은 원료에 착색시키는 방식이라고 가정한다.]

 

자, 상단의 물건은 생성될 수 있는 목록이 자그마치 135종이나 된다. 공장에서 이 많은 종류를 모두 개별 생산 라인으로 구축하려면 어마어마하게 넓은 공장 부지가 필요할 것이고, 특정 물건의 소요가 줄었을 때의 비효율도 매우 커지게 될 것이다.

때문에, 생산 공정을 공유시킬 수 있는 것들은 공유시키고, 유리해야 하는 것들은 유리시키는 방식으로 운영할 것이라고 추측할 수 있다.

[물론, 잔류 원료 등의 문제로 실제 상황은 다를 수 있겠지만, 설명을 위해서 이런 경우는 제외하였다.]

 

이 방식을 프로그래밍에 접목시킨 것이 바로 추상 팩토리이다.

같은 라인(함수명)으로 물건을 제작하기 위해서 제작 공정(인터페이스)이 공유 혹은 구분되는 각 제작 라인(클래스)를 제작하는 방식인 것.

[공장이라는 묘사 상, 이 관계가 역전된 것으로 착각하기가 쉬우나, 그렇지 않다는 것을 유의하자.]

 

이렇게 보면 클래스 수가 어마어마하게 증가하지 않겠느냐 싶을텐데, 그렇게 한다고 해도 '명확하게 결과물이 명시되는 구조'가 더 중요하기 때문에 이쪽이 더 이득이다.

어차피 클래스들은 폴더로 묶으면 되기도 하니 말이다.

---

팩토리 메서드

[URL: https://refactoring.guru/ko/design-patterns/factory-method]

자, 이미 잘 굴러가고 있던 클래스가 하나 있다고 가정하자.

이 클래스는 정상 작동이 되고 있지만, 

이 기능에 대응하는 다른 기능을 추가해야 하게 되었다.

일반적인 구조에서, 이럴 때에 선택할 수 있는 방법은 다음 2가지 정도로 정리할 수 있을 것이다.

1. 기존에 사용하던 클래스를 리팩토링하여 이에 대응하는 기능을 추가할 수 있는 환경을 만들기
2. 새롭게 제작하는 기능을 별개의 구성으로 작업하기.

1번은 지금까지 잘 굴러가던 코드를 굳이 뜯어서 고쳐야하고, 2번은 스파게티 코드로 가는 지름길이다.

 

이럴 때에 쓸 수 있는 3번 선택지가 있다. 바로 '기존 클래스의 부모 클래스를 정의하고, 이를 상속받는 자식 클래스로 신규 기능을 작업하는 것.

해당 클래스의 기능 메서드나 초기화 함수 등의 추상 함수를 부모 클래스가 들고있도록 하고, 이를 오버라이딩 하는 방식으로 구현하는 것이다.

이러면 부모 클래스의 추상 함수를 이용해서 자식 클래스의 함수에 접근할 수 있게 되고, 이에 더해서 사용 방법을 그대로 유지하면서 기능을 추가할 수 있는 기반이 만들어지게된다.

---

본인은 디자인 패턴에 대해서 정리할 때 항상 디자인 패턴에 정답은 없다는 것을 강조했었다.

당연한 것이다. 디자인 패턴은 정답이 아니라 노하우인 것이니까.

그래도 알아두면 쓸 곳은 많다. 공부하자. 더욱 넓게 볼 내일을 위해서.