팩토리 메소드 패턴 - 팩토리 메소드 패턴에서는 객체를 생성하기 위한 인터페이스를 정의하는데, 어떤 클래스의 인스턴스를 만들지는 서브클래스에서 결정하게 만든다. 팩토리 메소드 패턴을 이용하면 클래스의 인스턴스를 만드는 일을 서브클래스에게 맡기는 것이다.
팩토리 메소드 패턴에서는 어떤 클래스의 인스턴스를 만들지를 서브클래스에서 결정한다. 패턴을 사용할 때 서브클래스에서 실행중에 어떤 클래스의 인스턴스를 만들지를 결정하기 때문이 아니라, 생산자 클래스 자체가 실제 생산될 제품에 대한 사전 지식이 전혀 없이 만들어 지기 때문이다. 더 정확하게 표현하자면, 사용하는 서브클래스에 따라 생산되는 객체 인스턴스가 결정될 것이다.
Q: 간단한 팩토리와 팩토리 메소드 패턴의 차이점을 아직 잘 모르겠어요. 팩토리 메소드 패턴에서는 피자를 리턴하는 클래스가 서브클래스라는 점을 제외하면 거의 똑같잖아요.
A: 팩토리 메소드 패턴이 간단한 팩토리와 상당히 비슷하다는 지적은 맞으나 간닪나 팩토리는 일회용 처방에 불과한 반면, 팩토리 메소드 패턴을 이용하면 어떤 구현을 사용할지를 서브클래스에서 결정하는 프레임워크를 만들 수 있다는 결정적인 차이점이 있다. 예를 들어, 팩토리 메소드 패턴에서 사용한 orderPizza() 메소드에서는 피자를 만들기 위한 일반적인 프레임워크를제공한다. 그 프레임워크에서는 팩토리 메소드를 이용하여 피자를 만드는 구상 클래스를 만들었었다. PizzaStore 클래스의 서브클래스를 만들 때, 어떤 구상 제품 클래스에서 orderPizza()에서 리턴할 피자를 만들지를 결정하게 된다. 이 Framework를 간단한 Factory하고 한번 비교해 보아라. 간단한 Factory에서는 객체생성을 캡슐화하는 방법을 사용하긴 하지만 Factory Method Pattern처럼 강력한 유연성을 제공하진 못한다. 생성하는 제품을 마음대로 변경할 수 없기 때문이다.
- 바뀌는 부분을 캡슐화하라!
- 객체를 생성하는 코드를 캡슐화할 수 있다.
- 팩토리를 썼을 때의 장점
1) 객체 생성 코드를 전부 한 객체 또는 메소드에 집어넣으면 코드에서 중복되는 내용을 제거할 수 있고, 나중에 관리할 때도 한군데에만 신경을 쓰면 된다.
2) 클라이언트 입장에서는 객체 인스턴스를 만들 때 필요한 구상 클래스가 아닌 인터페이스만 필요로 하게 된다. => 이 방법을 도입 시 구현이 아닌 인터페이스를 바탕으로 프로그래밍을 할 수 있고, 유연성과 확장성이 뛰어난 코드를 만들 수 있게 된다.
의존성 뒤집기 원칙(Dependency Inversion Principle)
구상 클래스에 대한 의존성을 줄이는 것이 좋다!!
디자인 원칙 : 추상화된 것에 의존하도록 만들어라. 구상 클래스에 의존하도록 만들지 않도록 한다. == "특정 구현이 아닌 인터페이스에 맞춰서 프로그래밍한다"는 원칙과 같다.
의존성 뒤집기 원칙에는 고수준 구성요소가 저수준 구성요소에 의존하면 안 된다는 것이 내포되어 있다. 항상 추상화에 의존하도록 만들어야 한다.
의존성 뒤집기를 한다는 말은 객체지향 디자인을 할 때 일반적으로 생각하는 방법과는 반대로, 뒤집에서 생각해야 하기 때문이다.
팩토리 메소드 패턴에서는 어떤 클래스의 인스턴스를 만들지를 서브클래스에서 결정한다. 패턴을 사용할 때 서브클래스에서 실행중에 어떤 클래스의 인스턴스를 만들지를 결정하기 때문이 아니라, 생산자 클래스 자체가 실제 생산될 제품에 대한 사전 지식이 전혀 없이 만들어 지기 때문이다. 더 정확하게 표현하자면, 사용하는 서브클래스에 따라 생산되는 객체 인스턴스가 결정될 것이다.
Q: 간단한 팩토리와 팩토리 메소드 패턴의 차이점을 아직 잘 모르겠어요. 팩토리 메소드 패턴에서는 피자를 리턴하는 클래스가 서브클래스라는 점을 제외하면 거의 똑같잖아요.
A: 팩토리 메소드 패턴이 간단한 팩토리와 상당히 비슷하다는 지적은 맞으나 간닪나 팩토리는 일회용 처방에 불과한 반면, 팩토리 메소드 패턴을 이용하면 어떤 구현을 사용할지를 서브클래스에서 결정하는 프레임워크를 만들 수 있다는 결정적인 차이점이 있다. 예를 들어, 팩토리 메소드 패턴에서 사용한 orderPizza() 메소드에서는 피자를 만들기 위한 일반적인 프레임워크를제공한다. 그 프레임워크에서는 팩토리 메소드를 이용하여 피자를 만드는 구상 클래스를 만들었었다. PizzaStore 클래스의 서브클래스를 만들 때, 어떤 구상 제품 클래스에서 orderPizza()에서 리턴할 피자를 만들지를 결정하게 된다. 이 Framework를 간단한 Factory하고 한번 비교해 보아라. 간단한 Factory에서는 객체생성을 캡슐화하는 방법을 사용하긴 하지만 Factory Method Pattern처럼 강력한 유연성을 제공하진 못한다. 생성하는 제품을 마음대로 변경할 수 없기 때문이다.
- 바뀌는 부분을 캡슐화하라!
- 객체를 생성하는 코드를 캡슐화할 수 있다.
- 팩토리를 썼을 때의 장점
1) 객체 생성 코드를 전부 한 객체 또는 메소드에 집어넣으면 코드에서 중복되는 내용을 제거할 수 있고, 나중에 관리할 때도 한군데에만 신경을 쓰면 된다.
2) 클라이언트 입장에서는 객체 인스턴스를 만들 때 필요한 구상 클래스가 아닌 인터페이스만 필요로 하게 된다. => 이 방법을 도입 시 구현이 아닌 인터페이스를 바탕으로 프로그래밍을 할 수 있고, 유연성과 확장성이 뛰어난 코드를 만들 수 있게 된다.
의존성 뒤집기 원칙(Dependency Inversion Principle)
구상 클래스에 대한 의존성을 줄이는 것이 좋다!!
디자인 원칙 : 추상화된 것에 의존하도록 만들어라. 구상 클래스에 의존하도록 만들지 않도록 한다. == "특정 구현이 아닌 인터페이스에 맞춰서 프로그래밍한다"는 원칙과 같다.
의존성 뒤집기 원칙에는 고수준 구성요소가 저수준 구성요소에 의존하면 안 된다는 것이 내포되어 있다. 항상 추상화에 의존하도록 만들어야 한다.
의존성 뒤집기를 한다는 말은 객체지향 디자인을 할 때 일반적으로 생각하는 방법과는 반대로, 뒤집에서 생각해야 하기 때문이다.
- 원칙을 지키는 데 도움이 될만한 가이드라인...
1) 어떤 변수에도 구상 클래스에 대한 레퍼런스를 저장하지 맙시다.
: new 연산자를 사용하면 구상 클래스에 대한 레퍼런스를 사용하게 되는 것이다. 팩토리를 써서 구상 클래스에 대한 레퍼런스를 변수에 저장하는 일을 미리 방지하자.
2) 구상 클래스에서 유도된 클래스를 만들지 말자.
: 구상 클래스에서 유도된 클래스를 만들면 특정 구상 클래스에 의존하게 된다. 인터페이스나 추상 클래스처럼 추상화된 것으로부터 클래스를 만들어야 한다.
3) 베이스 클래스에 이미 구현되어 있던 메소드를 오버라이드하지 말자.
: 이미 구현되어 있는 메소드를 오버라이드한다는 것은 애초부터 베이스 클래스가 제대로 추상화 된 것이 아니었다고 볼 수 있다. 베이스 클래스에서 메소드를 정의할 때는 모든 서브클래스에서 공유할 수 있는 것만 정의 해야 한다.
WRITTEN BY
- 정현석
이것저것 끄적끄적....
,
