위 슈 의 마법 세상 : : Factory Method Pattern ( 팩토리 메 서드 패턴 ) 
 39 . .. 16 
 Factory Method Pattern ( 팩토리 메 서드 패턴 ) 
 Design Patterns / 영문 위키 ( Wikipedia ) 2012 . 04 . 24 01 : 30 | 
 이 글 은 영문 위키피디아 페이지 를 번역 한 글 임 을 먼저 알려 드립니다 . 
 영어 실력 이 부족 해서 다소 오역 이 있 을 수 도 있 습니다 . 
 원문 주소 : http : / / en . wikipedia . org / wiki / Factory _ method _ pattern 
 생성 패턴 - Factory Method Pattern 
 팩토리 메 서드 패턴 은 공장 의 개념 을 구현 하 기 위한 객체 지향 디자인 패턴 이 다 . 다른 생 성 패턴 ( creational patterns ) 들 과 마찬가지 로 이 패턴 은 생성 할 객체 에 대한 정확 한 클래스 를 구분 할 필요 없이 ( 알 필요 없이 ) 객체 를 생성 하 는 것 에 대한 문제 를 다룬다 . 주로 객체 를 생성 할 때 보 면 , 그 객체 를 결합 하 는 ( 사용 하 는 ) 객체 에서 는 굳이 필요 하 지 않 은 복잡 한 과정 이 필요 하 다 . 객체 의 생 성 은 심각 한 코드 의 중복 을 야기 할 수 있 고 , 결합 하 는 ( 사용 하 는 ) 객체 에서 접근 할 수 없 는 정보 들 을 요구 할 수 도 있 으며 , 충분 한 추상 화 단계 를 제공 하 기 힘들 수 도 있 고 , 결합 하 는 ( 사용 하 는 ) 객체 의 관심사 에 는 포함 되 지 않 을 수 도 있 다 . 팩토리 매서 드 패턴 은 객체 를 생성 할 때 별도 의 메서 드 를 정의 하 고 , 서브 클래스 에서 생성 될 객체 의 종류 를 정할 수 있 게 함 으로써 이런 문제 들 을 해결 한다 . 
 객체 의 생 성 에 필요 한 과정 들 을 보 면 , 객체 의 생명 주기 를 다루 는 문제 가 포함 되 고 , 객체 의 생성 ( build - up ) 과 파괴 ( tear - down ) 에 관련 된 구체 적 인 문제 를 다루 는 것 도 포함 된다 . 디자인 패턴 의 범위 밖 에서 봐도 , 팩토리 매서 드 라는 용어 또한 팩토리 ( 여기 에서 팩토리 의 주 목적 은 객체 생성 이 다 . ) 의 메서 드 를 지칭 할 수 도 있 다 . 
 정의 Definition 
 팩토리 매서 드 패턴 의 진수 는 " 객체 의 생 성 에 관련 된 인터페이스 를 정의 하 고 , 인터페이스 를 구현 하 는 클래스 에서 어떤 클래스 를 인 스턴스 화 ( 생성 ) 할 것 인지 정하 게 두 는 것 이 다 . 즉 팩토리 메서 드 는 서브 클래스 에서 인 스턴스 화 를 하 도록 미루 는 것 이 다 . " 
 일반 적 인 사용 Common usage 
 팩토리 메서 드 는 툴킷 과 프레임 웍 에서 일반 적 으로 사용 된다 . 라이브러리 코드 에서 객체 를 생성 할 필요 가 있 는데 , 그 객체 는 프레임 웍 을 사용 하 는 애플리케이션 에 의해 서브 클 래 싱 될 수 도 있 을 것 이 다 . 
 평행 한 클래스 계층 에서 는 주로 다른 계층 으로부터 적절 한 객체 를 생성 하 는 것 이 가능 하 도록 한 계층 으로부터 객체 를 요구 한다 . 
 팩토리 메서 드 는 TDD ( test - driven development ) 에서 클래스 를 테스트 하 기 위해 사용 됩니다 . 만약 Foo 라는 클래스 가 Dangerous 라는 객체 를 생성 하 는데 이 Dangerous 객체 가 유닛 테스트 에 사용 될 수 없 을 수 있 습니다 . ( Dangerous 객체 가 데이터 베이스 와 통신 을 하 는데 , 이 데이터베이스 가 사용 불 가능 할 수 도 있 는 경우 ) 이럴 때 Dangerous 객체 의 생 성 을 Foo 클래스 의 가상 의 팩토리 매서 드 인 createDangerous 에 둘 수 있 습니다 . 테스트 를 위해서 TestFoo ( Foo 클래스 의 서브 클래스 ) 를 만들 고 가상 의 팩토리 메서 드 인 createDangerous 를 오버 라 이드 해서 FakeDangerous ( 말 그대로 가짜 객체 입니다 . ) 라는 객체 를 반환 할 수 있 겠 죠 . 그러면 유닛 테스트 에서 TestFoo 를 사용 해서 Foo 클래스 의 기능 을 테스트 할 수 있 습니다 . Foo 클래스 를 그대로 사용 했 을 때 Dangerous 객체 의 부작용 ( 데이터베이스 가 사용 불 가능 한 상황 ) 이 생길 수 있 는데 이러 한 부작용 없이 테스트 가 가능 하 겠 죠 . 
 적용 가능 성 Applicability 
 팩토리 메서 드 는 다음 과 같 은 상황 에서 사용 될 수 있 다 . 
 한 객체 의 생 성 이 코드 의 중복 없이 재 사용 하 는 것 을 못 하 도록 하 는 상황 일 때 
 한 객체 의 생 성 이 결합 하 는 ( 사용 하 는 ) 클래스 에서 필요 하 지 않 은 정보 나 리소스 에 접근 해야 할 때 
 애플리케이션 에서 일관 성 있 는 동작 을 하 기 위해 생성 된 객체 의 살 아 있 는 시간 ( lifetime ) 의 관리 가 중앙 에서 관리 할 필요 가 있 을 때 
 다른 이점 과 변종 Other benefits and variants 
 팩토리 메 서드 패턴 의 뒤 에 있 는 동기 는 서브 클래스 에게 어떤 타입 의 객체 를 생성 할지 선택 하 는 것 을 허락 하 는 것 이 지만 , 팩토리 메서 드 를 사용 하 는 데 에 는 다른 이점 도 있 다 . 이런 이익 의 대부분 은 서브 클 래 싱 의 의존 하 지 않 는다 . 이런 다른 이점 을 위해 객체 를 생성 하 는 데 에 다 형성 ( polymorphic ) 을 사용 하 지 않 고 팩토리 메서 드 를 정의 하 는 것 이 일반 적 이 고 , 그러 한 메 서드 는 종종 static 메 서 드이 다 . 
 서술 적 인 이름 Descriptive names 
 팩토리 매서 드 는 특별 한 이름 을 가지 고 있 다 . 많 은 객체 지향 언어 에서 생성자 는 클래스 이름 과 같 아야 하 는데 , 이 는 객체 를 생 서 하 는 방법 이 한 가지 이상 일 경우 에 모호 성 을 야기 할 수 있 다 . 팩토리 메 서드 에서 는 그러 한 제약 이 없 고 서술 적 인 이름 을 가질 수 있 다 . 예 를 들 자면 , 복수 ( complex numbers ) 가 두 개 의 실수 로 만들 어 진다면 , 이 두 개 의 실수 는 카테 시안 좌표계 나 극 좌표계 로 해석 되 어 질 수 있 다 . 하지만 팩토리 매서 드 를 사용 했 을 때 에 는 그 의미 가 확실 해진다 . 
 ( 아래 는 자바 에서 의 예 이 다 . ) 
 이 와 같이 팩토리 메 서드 가 명확 화 를 위해 사용 될 때 에 는 , 클라이언트 에서 팩토리 메서 드 를 통해서 객체 를 생성 할 수 밖 에 없 게끔 생성자 는 주로 private 으로 만들 어 진다 . 
 캡슐 화 Encapsulation 
 팩토리 메서 드 는 객체 의 생 성 을 캡슐 화 한다 . 이 는 생 성 절차 가 매우 복잡 한 경우 에 유용 할 수 있 다 . 예 를 들 면 , 설정 파일 이나 사용자 의 입력 에 따라 객체 생성 과정 이 달라질 때 말 이 다 . 
 이미지 파일 을 읽 어서 섬네일 을 만드 는 프로그램 을 생각 해 보 자 . 그 프로그램 은 각 포 멧 에 대해 리더 클래스 ( reader class ) 로 표현 되 는 다른 이미지 포맷 을 지원 한다 . 
 이 프로그램 은 매번 이미지 를 읽 을 때 마다 파일 에 있 는 정보 에 기반 해 적절 한 타입 의 리더 를 생생 하 는 과정 이 필요 하 다 . 이러 한 로직 은 팩토리 메서 드로 캡슐 화 할 수 있 다 . 
 앞 에 나온 예제 에서 코드 조각 ( fragment ) 은 이미지 타입 과 특정 팩토리 객체 를 연결 하 기 위해서 스위치 문 ( switch ) 을 사용 한다 . 이 방법 을 대신 해서 이러 한 관계 는 맵 핑 ( mapping ) 으로 도 구현 될 수 있 다 . 이 는 스위치 문 을 associatvie array 로 대체 할 수 도 있 음 을 말 한다 . 
 구현 예 Example Implementations 
 두 가지 모드 로 즐길 수 있 는 미 로 게임 . 첫 번 째 모드 는 보통 의 방 들 이 인접 한 방 에 만 연결 이 되 어 있 는 모드 이 고 , 두 번 째 모드 에서 는 마술 방 이 있 는데 이 방 은 플레이어 를 랜덤 한 위치 로 이동 시켜 준다 . 보통 게임 모드 ( 첫 번 째 모드 ) 는 템플 릿 메 서 드 를 사용 해서 구현 할 수 있 다 . 
 위 의 코드 토막 에서 MazeGame 생성자 는 공통 로직 을 만드 는 템플 릿 메 서 드이 다 . 이 생성자 는 makeRoom ( ) 팩토리 메서 드 를 호출 하 는데 , 이 팩토리 메서 드 는 서브 클래스 에서 사용 될 수 있 는 다른 방 들 의 생 성 을 캡슐 화 하 고 있 다 . 마술 방 을 가지 고 있 는 다른 게임 모드 ( 두 번 째 모드 ) 를 구현 하 기 위해 makeRoom ( ) 메서 드 를 오버 라이드 해야 한다 . 
 한계 Limitations 
 팩토리 메서 드 를 사용 하 는 데 에 는 3 가지 한계점 이 있 다 . 첫 번 째 는 기존 코드 를 리팩토링 하 는 것 과 관련 이 있 고 , 나머지 두 가지 는 클 래스 를 확장 하 는 것 과 ( 클래스 상속 ) 관련 이 있 다 . 
 첫 번 째 한계 는 팩 토리 를 사용 하 기 위해 기존 클래스 를 리팩토링 하 는 것 이 기존 클라이언트 코드 를 깬다 ( break ) 는 점 이 다 . 예 를 들 어 , Complex 클래스 가 표준 ( standard ) 클래스 였 다고 하 면 , 이 클래스 는 다음 코드 와 같이 많 은 클라이언트 를 가지 고 있 을지 도 모른다 . ( 여기 에서 클라이언트 는 Complex 클래스 를 사용 하 는 클래스 를 의미 하 는 것 같 네요 . ) 
 일단 우리 가 다른 두 개 의 팩토리 가 필요 하 다는 사실 을 알 게 된다면 , 우리 는 그 클래스 를 바꿀 것 이 다 . 하지만 이제 생성자 가 private 이 되 었 기 때문 에 기존 클라이언트 코드 는 더 이상 컴파일 이 안 된다 . ( 사용 할 수 없 다 . ) 
 두 번 째 한계 는 private 생성자 를 사용 하 기 때문 에 해당 클래스 를 확장 할 수 없 다 ( 상속 받 을 수 없 다 ) 는 점 이 다 . 서브 클래스 는 상속 받 은 생성자 를 호출 해야 만 하 지만 , 생성자 가 private 이 라면 이 는 불 가능 한 일 이 다 . 
 세 번 째 한계 는 만약 우리 가 그 클래스 를 확장 한다면 ( 예 를 들 어 생성자 를 protected 로 만듦으로써 가능 하 다 - 이 는 위험 하 지만 실현 가능 하 다 . ) , 서브 클래스 는 부모 가 가지 고 있 는 모든 팩토리 메서 드 를 완전히 같 은 시그 너 쳐 ( signature , 같 은 인자 를 가지 는 메서 드 를 의미 하 는 듯 ? ) 를 가지 고 재 구현 해야 만 한다 . 예 를 들 어 , StrangeComplex 가 Complex 클래스 를 확장 하 는데 StrangeComplex 가 부모 의 모든 팩토리 메서 드 를 재 구현 하 지 않 는다면 StrangeComplex . fromPolar ( 1 , pi ) 같 은 팩토리 메서 드 를 호출 할 때 서브 클 래스 인 StrangeComplex 의 객체 가 생성 되 는 게 아니 라 , 수퍼 클래스 인 Complex 객체 가 생성 될 것 이 다 . 
 이 세 가지 문제 들 은 모두 팩 토리 를 최상위 클래스 멤버 로 만듦으로써 완화 시킬 수 있 는 문제 들 이 다 . ( 잘 이해 는 안 되 지만 아마 팩 토리 에서 생성 하 는 객체 를 Abstract Class 또는 Virtual Class 또는 Interface 로 만들 면 해결 된다는 것 같 기 도 하 다 . ) 
 Adapter Pattern ( 어댑터 패턴 ) ( 0 ) 
 Singleton pattern ( 싱글톤 ) ( 0 ) 
 Prototype pattern ( 프로토타입 패턴 ) ( 0 ) 
 Builder Pattern ( 빌더 패턴 ) ( 0 ) 
 Abstract Factory Pattern ( 추상 팩토리 패턴 ) ( 0 ) 
 Factory Method Pattern ( 팩토리 메 서드 패턴 ) ( 0 ) 
 TAG creational , design pattern , Factory Method , 디자인 패턴 , 생 성 , 팩토리 메 서드 
 Trackback 9 : Comment 0 
 PREV 1 · · · 27 28 29 30 31 32 33 34 35 · · · 106 NEXT