Abstract factory 패턴
- 추상 팩토리 패턴은 관련성 있는 여러 종류의 객체를 일관된 방식으로 생성하는 경우에 유용하다.
- 계속되는 엘리베이터 예제에서 벤더에 따른 코드를 작성하면 벤더가 바뀌었을때 모든 부품의 코드가 벤더를 이동해야한다.
- 이런 경우에 부품별로 Factory를 정의하는 대신 관련 객체들을 일관성 있게 생성 할 수 있도록 Factory클래스를 정의하는 것이 효과적이다.
- 예를들어 Motor클래스를 위한 MotorFactory나 Door클래스를 위한 DoorFactory 대신 벤더에 따른 Factory를 정의하는것이 바람직하다.
엘리베이터 벤더 변경하기
- 엘리베이터를 구성하는 많은 부품 중에서 모터와 문을 생각해보자. 오티스는 오티스 모터와 오티스 문을 제공하고 현대는 현대 모터와 현대 문을 제공할 것이다.
- 엘리베이터만 생각하면 여러 제조 업체의 부품을 사용하더라도 같은 동작을 지원하는 것이 바람직하다. 예를 들어 서초 건물에는 오티스의 부품이 사용되고 개포동 건물에서는 현대의 부품이 사용되더라도 엘리베이터 프로그램의 변경을 최소화 할 필요가 있다.
- 다음은 상속설계된 클래스 다이어그램이다
- 템플릿 메소드 패턴을 이용해 작성한 Door와 그 구현 코드다. – 코드 보기 / 구현 코드
- 그리고 각 문을 생성해주는 팩토리 메소드 패턴의 DoorFactory 코드다 – 코드 보기
- 템플릿 메소드 패턴의 Motor 코드 – 코드 보기 / 구현 코드
- 각 모터를 구동하는 팩토리 메소드 패턴의 MotorFactory코드 – 코드 보기
- 실행하기 위한 main() – 코드 보기
- 실행결과
Opening Otis Door.
Closing Otis Door.
Moving OtisMotor UP중간에 코드가 많이 비어있어서 실행되도록 채워넣느라 힘들었다..
문제점
- 타 벤더의 부품으로 바꿔야 한다면?
- 여기에 새로운 벤더의 부품을 지원해야 한다면?
타 벤더의 부품으로 바꿔야하는 경우
- 현재는 Door와 Motor뿐이지만 엘리베이터에는 이것 말고도 스피커, 버튼, 층표시 디스플레이 등 여러가지 부품들이 있다. 이 모든 부품들의 벤더를 매번 바꿔야 한다면 적절한 방법이 아니다.
새로운 벤더으 부품을 지원해야 하는 경우
- 역시 Door와 Motor뿐이지만 여기에 다른 벤더가 추가된다면 각 팩토리 객체마다 벤더를 추가해줘야된다. 적절한 방법이 아니다.
해결책
- 엘리베이터는 벤더의 모터와 문을 제어할 필요가 있다. 그런데 일반적으로 오티스를 쓴다면 오티스 부품을, 현대를 쓴다면 현대 부품을 사용한다. 이같이 여러 종류의 객체를 생성할 때 객체들 사이에 관련성이 있는 경우라면 각 부품별 Factory클래스 대신 관련성 있는 객체들을 일관성 있는 Factory로 묶어주는것이 편리하다
- MotorFactory나 DoorFactory대신 OtisElevatorFactory나 HyundaiElevatorFactory가 적절하다는 이야기다.
- 각 ElevatorFactory의 클래스 일반화
Opening Hyundai Door.
Closing Hyundai Door.
Moving HyundaiMotor UP