Stonze Week1Abstract Factory Pattern

• Abstract Factory Pattern

제품을 이루고 있는 여러 객체 생성에 유용한 패턴Ex) 자동차 제품군 : 엔진 , 기어 , 브레이크 , 바퀴 등등으로 구성어떤 자동차를 만드냐에 따라서 엔진 , 기어 , 브레이크 또한 각각에 맞는 제품을 필요로 한다스포츠카에 티코 바퀴 달면 안된다 !! 각 제품군 ( 스포츠카 , 티코 ) 은 각 제품군에 맞는 객체들을 생성해야한다 .

• Abstract Factory Pattern

제품을 이루고 있는 여러 객체 생성에 유용한 패턴게임을 예로 들어보자 .Ex) 스타크래프트 : 어느 종족이든 본진과 일꾼이 게임시작 할 때 생성해야 한다 .

저그로 종족 선택했는데 해처리랑 SCV 가 나온면 안된다 .즉 저그로 종족 선택을 했으면 반드시 해처리와 드론이 세트로 생성되어야 한다 .

• Abstract Factory Pattern

그렇다면 종족이 결정되었을 때마다 어떻게 그 종족에 맞는 본진과 일꾼들을 시작할 때 생성하도록 할 수 있을까 ? 즉 , 종족이 결정되면 그에 맞는 본진과 일꾼들을 첫 시작시에 생성하도록 보장할 수 있을 것인가 ?

• 문제 해결 사항- 게임을 시작한다- 종족을 선택한다 .- 종족에 맞는 본진을 가진다 ( 저그 : 해처리 , 테란 : 커맨드센터 , 프로토스 : 넥서스 )- 각 종족은 자원을 캘 일꾼을 가진다 ( 저그 : 드론 , 테란 : SCV , 토스 : 프로브 )- 게임 시작과 함께 각 종족에 맞는 본진 + 일꾼을 셋트로 생성해야 한다 .

enum 및 Class 정의

• 직접 타입 조건 체크 사용하여 객체생성

• 직접 타입 조건 체크 사용하여 객체생성 – 그림으로

테란 제품군 생성 토스 제품군 생성 저그 제품군 생성본진 , 일꾼을 생성하는 각각의 코드가 존재한다 . 각각의 코드에서 해당 객체 직접 생성

• 직접 타입 조건 체크 사용하여 객체생성< 장점 >- 매우 직관적이고 , 쉽다 .

< 단점 >- 직접 생성하는 코드이므로 코드의 추가 , 수정 , 변경 , 삭제 등이 발생시 직접 해당 구현 부분을 찾아서 + 고쳐야 한다 .

- Ex) 제 4 의 종족이 추가된다면 각각의 본진과 일꾼 생성하는 코드를 찾고 + 추가 해야 한다 .- 직접 코드로 제어하기 때문에 해당 객체의 생성이 필요한 곳에서 중복 코드가 발생한다 .

- Ex) melee, free for all, team 의 모드에서 각각의 코드가 모두 중복해서 필요하다- 실수를 유발하기 쉽다 .

• 객체 생성 전담 클래스 활용- Simple Factory 라고도 함 ( 패턴이라고 일컫지는 않음 )- 해당 클래스에서 객체생성을 전담함

• 객체 생성 전담 클래스 활용< 장점 >- 하드코딩 된 객체생성 코드가 여기저기에 중복 사용되고 있는 문제점을 해결- 변경될 가능성이 많은 부분을 한곳으로 모아서 유지 보수 및 변경에 유연하게 대처< 단점 >- 여전히 타입에 따른 조건 체크를 이용하는 코드가 존재함 .- 제 4 의 종족이 추가된다면 역시 해당 코드의 타입 조건 체크 코드를 각각 추가 해야함 .

• 객체 생성 전담 클래스 활용 – 그림으로

테란 제품군 생성 토스 제품군 생성 저그 제품군 생성본진 , 일꾼을 생성하는 객체생성 클래스가 존재한다 . 해당 클래스에서 객체 생성관리 .

• Abstrac Factory Pattern 활용- 제품군을 구성하는 클래스의 객체를 생성하는 클래스- 새로운 제품군을 추가하는 것이 쉽도록 상속을 도입- 구체적인 제품군별 객체를 생성하는 구현 클래스 존재- 구현 클래스는 상위의 Abstract Base Class 를 상속받아 구현

- 게임 스타트시 제품군을 표현하는 최상위클래스 ( 인터페이스 제공 )- 저그로 스타트시 알맞은 제품을 생성하는 제품군 클래스- 테란으로 스타트시 알맞은 제품을 생성하는 제품군 클래스- 프로토스로 스타트시 알맞은 제품을 생성하는 제품군 클래스- 각 종족별 제품군 클래스는 최상위 클래스를 상속받아 구체적인 객체 생성

• Abstrac Factory Pattern 활용

• Abstrac Factory Pattern 활용각각의 종족별 본진 + 일꾼을 한 Set 으로 만들어 객체 생성 각 종족에 맞는 Factory Class

• Abstrac Factory Pattern 활용 – 그림으로

테란 제품군 생성 토스 제품군 생성 저그 제품군 생성본진 + 일꾼 세트를 생성하는 Factory 클래스가 존재한다 . 해당 클래스에서 자기 자신이 생성하는 객체들 생성

• Abstrac Factory Pattern 활용< 장점 >- 직접 조건 활용이나 객체 전담 클래스에서 필요했던 타입에 다른 조건 체크가 필요 없음- 직접 조건 활용이나 객체 전담 클래스에서 객체 생성에 수정이 필요하다면 직접 해당 조건에 대해 알맞은 작업내용을 코드로 추가해야 했다 . 하지만 Abstract Factory Pattern 에서는 해당 객체 생성 수정이 필요한 Factory Class 에서만 수정 변경하므로 의존성이 없음- 어떤 Factory Class 를 활용하여 제품군을 생성할 것인지 정해지면 나머지 객체 생성에 있어서 조건 체크가 필요 없음- 이전 코드에 대한 분석 및 수정이 필요 없이 독립적으로 객체 생성을 가능하게 한다 . < 단점 >- 제 4 의 종족이 추가된다면 해당 종족에 대한 구현 Factory Class 가 추가되어야 함 .- 제 5, 6, 7 의 종족이 추가된다면 각각 Factory Class 를 구현해야 하므로 Factory Class 개수가 많아짐- Factory 자체 제품군이 추가된다면 모든 Factory Class 를 수정해야 한다 .

Ex) 각 종족 시작시 영웅을 한마리씩 준다고 게임 룰이 바뀐다면 ?

• Abstrac Factory Pattern 활용 – 단점 해결 방안- 보통 Abstract Factory Pattern 을 활용시 객체 생성을 하는 클래스는 고유한 경우가 많다 . 직관적으로 커맨드센터 + SCV 를 생성하는 제품군 Factory 클래스가 2 개이상이어야 할 이유는 없다 . 따라서 이런경우 Singleton 패턴을 적용시켜 특정 Factory Class 가 비효율적으로 2 개 이상 생성되는 것을 피할 수 있다 .

- Abstrac Factory Pattern 은 구현 Factory Class 가 늘어날 수 있다는 단점이 있다 . 이는 Prototype 패턴을 활용하여 해결할 수 있다 . 하지만 Prototype 패턴을 사용하면 Factory Class 에 객체의 인스턴스를 모두 가지고 있어야하는 부담이 따른다 . 또한 객체의 인스턴스를 제대로 정의하지않으면 제품군에 맞는 알맞은 객체 생성을 보장할 수 없다 .

- 만약 제품군 자체에 대한 수정변경이 있을경우 각 Factory Class 또한 수정 변경을 해주어야한다 . 이를 해결하기위해 다형성 + prototype 패턴을 활용한다 . 이에 대한 자세한 사항은 prototype 패턴을 공부한 후 다시 정리해보기로 한다 .

• Abstract Factory Pattern 활용 – 정리- 객체의 생성을 독립적으로 만드는데 아주 유리한 패턴- 여러 제품군이 있다면 특정한 제품군에 알맞은 객체를 생성하도록 보장하길 원할때 유용함- 여러 제품군이 있다면 어떤 제품군을 선택할 것인지 직관적이고 명료함- 제품군 생성에 대한 Abstract Class 를 활용하므로 , 구체적인 Factory Class 의 내부는 몰라도됨- 구체적인 객체생성에 대한 캡슐화와 정보은닉- 항상 Abstract Factory Pattern 이 유용한 것은 아니다 . 제품군에 대한 객체 생성이 단순명료하고 , 제품군 자체의 수가 적다면 Simple Factory 구현 만으로도 충분할 수 있다 . 이것을 판단할 수 있는 경험과 노하우를 쌓는 것이 중요하다 .

End참고자료 : GOF 디자인패턴 , HeadFirstDesignPattern, Wiki