[design-pattern][디자인패턴]빌더 패턴(Builder Pattern)이란?

[design-pattern][디자인패턴]빌더 패턴(Builder Pattern)이란?

빌더 는 복잡한 객체를 단계별로 생성할 수 있는 생성 디자인 패턴입니다. 패턴을 사용하면 동일한 구성 코드를 사용하여 개체의 다른 유형과 표현을 생성할 수 있습니다.

 

 

단점

많은 필드와 중첩된 개체를 번거롭게 단계별로 초기화해야 하는 복잡한 개체를 상상해 보십시오. 이러한 초기화 코드는 일반적으로 많은 매개 변수가 있는 괴물 같은 생성자 안에 묻혀 있습니다. 또는 더 나쁜 경우: 클라이언트 코드 전체에 흩어져 있습니다.

 

House예를 들어 객체 를 생성하는 방법에 대해 생각해 봅시다 . 간단한 집을 짓기 위해서는 네 개의 벽과 바닥을 만들고, 문을 설치하고, 한 쌍의 창을 맞추고, 지붕을 만들어야 합니다. 그러나 뒤뜰과 난방 시스템, 배관 및 전기 배선과 같은 기타 편의 시설이 있는 더 크고 밝은 집을 원하면 어떻게 해야 합니까?

가장 간단한 해결책은 기본 House클래스를 확장하고 매개변수의 모든 조합을 포함하는 일련의 하위 클래스를 만드는 것입니다. 그러나 결국 상당한 수의 하위 클래스로 끝납니다. 베란다 스타일과 같은 새로운 매개변수는 이 계층 구조를 더욱 확장해야 합니다.

번식 하위 클래스를 포함하지 않는 또 다른 접근 방식이 있습니다. House집 개체를 제어하는 ​​모든 가능한 매개 변수를 사용 하여 기본 클래스에서 바로 거대한 생성자를 만들 수 있습니다 . 이 접근 방식은 실제로 하위 클래스의 필요성을 제거하지만 또 다른 문제를 야기합니다.

매개변수가 많은 생성자에는 단점이 있습니다. 모든 매개변수가 항상 필요한 것은 아닙니다.

대부분의 경우 대부분의 매개변수는 사용되지 않으므로 생성자 호출이 매우 추해 집니다. 예를 들어, 일부 집에만 수영장이 있으므로 수영장과 관련된 매개변수는 10번 중 9번은 쓸모가 없습니다.

해결책

빌더 패턴은 자체 클래스에서 개체 구성 코드를 추출하여 빌더 라는 별도의 개체로 이동하도록 제안합니다 .

빌더 패턴을 사용하면 복잡한 객체를 단계별로 구성할 수 있습니다. 빌더는 제품이 빌드되는 동안 다른 개체가 제품에 액세스하는 것을 허용하지 않습니다.

패턴은 개체 구성을 일련의 단계( buildWalls, buildDoor등)로 구성합니다. 개체를 만들려면 빌더 개체에서 이러한 일련의 단계를 실행합니다. 중요한 부분은 모든 단계를 호출할 필요가 없다는 것입니다. 개체의 특정 구성을 생성하는 데 필요한 단계만 호출할 수 있습니다.

제품의 다양한 표현을 빌드해야 하는 경우 일부 구성 단계에서는 다른 구현이 필요할 수 있습니다. 예를 들어 오두막의 벽은 나무로 만들 수 있지만 성벽은 돌로 만들어야 합니다.

이 경우 동일한 빌드 단계 세트를 다른 방식으로 구현하는 여러 가지 빌더 클래스를 작성할 수 있습니다. 그런 다음 구성 프로세스(즉, 구성 단계에 대한 순서가 지정된 호출 집합)에서 이러한 빌더를 사용하여 다양한 종류의 객체를 생성할 수 있습니다.

다른 빌더는 다양한 방식으로 동일한 작업을 실행합니다.

예를 들어 나무와 유리로 모든 것을 짓는 건축업자, 돌과 철로 모든 것을 짓는 건축업자, 금과 다이아몬드를 사용하는 세 번째 건축업자를 상상해 보십시오. 동일한 단계를 호출하면 첫 번째 건축업자로부터 일반 주택, 두 번째 건축업자로부터 작은 성, 세 번째 건축업자로부터 궁전을 얻습니다. 그러나 이는 빌드 단계를 호출하는 클라이언트 코드가 공통 인터페이스를 사용하여 빌더와 상호 작용할 수 있는 경우에만 작동합니다.

감독

더 나아가 director 라는 별도의 클래스로 제품을 구성하는 데 사용하는 빌더 단계에 대한 일련의 호출을 추출할 수 있습니다 . director 클래스는 빌드 단계를 실행할 순서를 정의하고 빌더는 해당 단계에 대한 구현을 제공합니다.

감독은 작동하는 제품을 얻기 위해 실행해야 하는 구축 단계를 알고 있습니다.

프로그램에 디렉터 클래스가 반드시 필요한 것은 아닙니다. 항상 클라이언트 코드에서 직접 특정 순서로 빌드 단계를 호출할 수 있습니다. 그러나 director 클래스는 프로그램 전체에서 재사용할 수 있도록 다양한 구성 루틴을 배치하기에 좋은 장소일 수 있습니다.

또한 director 클래스는 클라이언트 코드에서 제품 구성의 세부 정보를 완전히 숨깁니다. 클라이언트는 빌더를 디렉터와 연결하고 디렉터와 함께 건설을 시작하고 빌더로부터 결과를 받기만 하면 됩니다.

 

 장점과 단점

• 개체를 단계별로 구성하거나 구성 단계를 연기하거나 반복적으로 단계를 실행할 수 있습니다.
• 제품의 다양한 표현을 구축할 때 동일한 구성 코드를 재사용할 수 있습니다.
•  단일 책임 원칙 . 제품의 비즈니스 로직에서 복잡한 구성 코드를 분리할 수 있습니다.

• 패턴에 여러 새 클래스를 생성해야 하므로 코드의 전반적인 복잡성이 증가합니다.

 

다른 패턴과의 관계

• 많은 디자인이 Factory Method (하위 클래스를 통해 덜 복잡하고 사용자 지정 가능)를 사용하여 시작하여 Abstract Factory , Prototype 또는 Builder (더 유연하지만 더 복잡함)로 발전합니다.
• 빌더 는 복잡한 객체를 단계별로 구성하는 데 중점을 둡니다. Abstract Factory 는 관련 개체의 패밀리를 만드는 데 특화되어 있습니다. Abstract Factory 는 제품을 즉시 반환하는 반면 Builder 는 제품을 가져오기 전에 몇 가지 추가 구성 단계를 실행할 수 있습니다.
• 구성 단계가 재귀적으로 작동하도록 프로그래밍할 수 있으므로 복잡한 복합 트리를 만들 때 빌더 를 사용할 수 있습니다 .
• Builder 와 Bridge 를 결합할 수 있습니다 . director 클래스는 추상화 역할을 하고 다른 빌더는 구현 역할을 합니다.
• 추상 팩토리 , 빌더 및 프로토타입 은 모두 싱글톤 으로 구현될 수 있습니다 .