Abstract Factory 는 이 책에서 설명하는 패턴 중 가장 난감한 것에 속하죠.
사실 Factory Method 까지만 이해하셔도 실생활에 응용하기엔 충분합니다.
Abstract Factory 는 Factory Method 를 여러개 중첩시켜 놓은 패턴이거든요.
좀 더 Flexibility (유연성?)를 주고자 한거죠.
책에서 설명한 것처럼 생성될 Object 가 여러개의 속성으로 구성되어 있으면,
그 각각의 속성을 다시 인터페이스로 만들어서 좀더 다양한 Object 을 생성할 수 있는 Factory 를 만들자는 거죠.
책에 나온 예제 그림을 보면,
Factory 인터페이스 자체가 여러개의 Factory Method 로 구성되어 있는게 보이시죠?
그것만 이해하시면 나머지는 어려울게 없어요.
좀 더 실질적인 예로 전자 상거래를 하는걸 생각해보면,
국내배송과 해외배송은 배송비나 부가가치세에서 차이가 나겠죠.
그러면 배송비에 대한 인터페이스를 만들어서, 두 가지 배송에 대한 클래스를 정의하고,
부가가치세에 대한 인터페이스를 만들어서, 또 두 가지 세율에 대한 클래스를 정의할 수 있죠.
그래서 최종 가격을 산출하는 Factory 인터페이스를 만들어서 하나는 국내 주문에 대한 Factory,
또하나는 해외 주문에 대한 Factory 클래스를 만듭니다.
물론 국내 주문에 대한 비용를 계산하는 클래스는 국내 배송비와 국내 부가가치세를 합산해서 계산하겠죠.
전자상거래 소프트웨어는 최종 가격을 산출하는 Factory 인터페이스만을 이용해서
이 모든 것을 추상화시켜 사용할 수 있습니다.
즉 필요한 Factory (국내 주문, 국제 주문)를 매개변수로 넘겨받아서 계산하는거죠.
물론 국내 주문 Factory 나 국제 주문 Factory 는 각각 필요한 배송비 클래스와 세금 클래스를 내부적으로 생성하겠죠.
여기서 재미있는 것이 주문 Factory 자체가 Factory Method 를 가지고 있다는 겁니다.
즉 주문 Factory 인터페이스엔 두개의 Factory Method 가 정의되어 있는데
하나는 배송비 계산 클래스를 만드는 거고, 또 하난 세금 클래스를 만드는 것이지요.
실제로 어떤 배송/세금클래스를 만드느냐는 것은 주문 Factory 인터페이스를 구현하는
국내주문 혹은 국제주문 Factory 클래스들에 정의되어 있는거죠.
그래서 제가 Factory Method 들의 중첩이라고 앞에 말씀드린거예요.
지금 예에선 두 가지 주문 종류밖에 없으니깐 뭐하러 이렇게 하느냐는 생각이 들텐데요,
만일 어떤 특정 국가가 우리나라와 면세 협정(tax treaty)를 맺었으면,
세율에 대한 클래스만 하나 더 만들어서,
새로운 주문 Factory 클래스를 만드는 것도 쉬운 일이죠.
기존의 방법으로 했으면 이런 예외 조항을 만드는 것이 프로그래머에겐 무지 귀찮은 일이 됩니다.
구지 단축키를 안해도..
간단하게 해결할 수 있는 방법은 set autochdir 을 쓰는 겁니다.
윈도 환경이면 _vimrc 에 "set autochdir"을 한 줄 추가하세요.
그럼 다음부터 파일을 열때마다 현재 디렉토리(Current Working Directory)가 자동으로 바뀝니다.
혹시 새로 생성하는 파일들에 대한 문제시면, 아예 바탕화면에 단축아이콘을 하나 생성하시고,
오른쪽 클릭하셔서 속성에서 "Start in"을 원하시는 경로로 바꾸어주세요.
(한글 윈도엔 뭐라고 되어 있을지 모르겠네요, 제가 미국에 살아서 한글 윈도를 접하기 힘들어요)
Start in -> '시작
Start in -> '시작 위치(S):'
답변감사합니다.
답변감사합니다. 이거... vim으로 자바 코딩하시는 분들께 꼭 알려드리고 싶은 팁이네요. 지난번도 그렇고 감사합니다.
ps. 아... violino님 추상 팩토리 때문에 너무 골치아파요. 팩토리 메서드 패턴은 어떻게 이해했는데... HFDP에서도 추상 팩토리 패턴에 대한 설명은 이해하기 어려운 부분이 있습니다. 클래스 다이어그램도 워낙 복잡하구요....
大逆戰
大逆戰
그게...
Abstract Factory 는 이 책에서 설명하는 패턴 중 가장 난감한 것에 속하죠.
사실 Factory Method 까지만 이해하셔도 실생활에 응용하기엔 충분합니다.
Abstract Factory 는 Factory Method 를 여러개 중첩시켜 놓은 패턴이거든요.
좀 더 Flexibility (유연성?)를 주고자 한거죠.
책에서 설명한 것처럼 생성될 Object 가 여러개의 속성으로 구성되어 있으면,
그 각각의 속성을 다시 인터페이스로 만들어서 좀더 다양한 Object 을 생성할 수 있는 Factory 를 만들자는 거죠.
책에 나온 예제 그림을 보면,
Factory 인터페이스 자체가 여러개의 Factory Method 로 구성되어 있는게 보이시죠?
그것만 이해하시면 나머지는 어려울게 없어요.
좀 더 실질적인 예로 전자 상거래를 하는걸 생각해보면,
국내배송과 해외배송은 배송비나 부가가치세에서 차이가 나겠죠.
그러면 배송비에 대한 인터페이스를 만들어서, 두 가지 배송에 대한 클래스를 정의하고,
부가가치세에 대한 인터페이스를 만들어서, 또 두 가지 세율에 대한 클래스를 정의할 수 있죠.
그래서 최종 가격을 산출하는 Factory 인터페이스를 만들어서 하나는 국내 주문에 대한 Factory,
또하나는 해외 주문에 대한 Factory 클래스를 만듭니다.
물론 국내 주문에 대한 비용를 계산하는 클래스는 국내 배송비와 국내 부가가치세를 합산해서 계산하겠죠.
전자상거래 소프트웨어는 최종 가격을 산출하는 Factory 인터페이스만을 이용해서
이 모든 것을 추상화시켜 사용할 수 있습니다.
즉 필요한 Factory (국내 주문, 국제 주문)를 매개변수로 넘겨받아서 계산하는거죠.
물론 국내 주문 Factory 나 국제 주문 Factory 는 각각 필요한 배송비 클래스와 세금 클래스를 내부적으로 생성하겠죠.
여기서 재미있는 것이 주문 Factory 자체가 Factory Method 를 가지고 있다는 겁니다.
즉 주문 Factory 인터페이스엔 두개의 Factory Method 가 정의되어 있는데
하나는 배송비 계산 클래스를 만드는 거고, 또 하난 세금 클래스를 만드는 것이지요.
실제로 어떤 배송/세금클래스를 만드느냐는 것은 주문 Factory 인터페이스를 구현하는
국내주문 혹은 국제주문 Factory 클래스들에 정의되어 있는거죠.
그래서 제가 Factory Method 들의 중첩이라고 앞에 말씀드린거예요.
지금 예에선 두 가지 주문 종류밖에 없으니깐 뭐하러 이렇게 하느냐는 생각이 들텐데요,
만일 어떤 특정 국가가 우리나라와 면세 협정(tax treaty)를 맺었으면,
세율에 대한 클래스만 하나 더 만들어서,
새로운 주문 Factory 클래스를 만드는 것도 쉬운 일이죠.
기존의 방법으로 했으면 이런 예외 조항을 만드는 것이 프로그래머에겐 무지 귀찮은 일이 됩니다.
좀 빈약한 설명이지만 이해에 도움이 되셨으면 해요.
윈도우라면
total commander를 쓰세요.
60%의 능률향상을 보장합니다.
F4 + :wq 끝
댓글 달기