head and first :factory Pattern

1. OOP의 5요소(SOLID)

•  단일 책임의 원칙(Single Resposiblility principle )
• 객체는 단 하나의 책임만 가지고 있어야한다.
• 클래스의 단일책임
• 리스코브 치환의 원칙
• 특정 클래스의 속성의 변경없이 , 기반클래스의(부모클래스) 객체가 서브클래스(자식클래스)의 객체로 변환될 수 있어야한다. 
• 인터페이스 분리의 원칙(Interface segregation principle)
• 어떤 클래스가 다른클래스에 종속될때 최소한의 인터페이스로 사용하여야한다
• 인터페이스의 단일책임
• 클래스 상속관계의 인터페이스 분리
• 객체 기능의 인터페이스 분리
• 의존 역전의 원칙(Dependancy Inversion Principle)
• 하위 모듈의 변경이 상위 모듈의 변경을 요구하는 위계관계를 끊는 의미역전 실질적으로 그렇지 않지만, 느슨한 결합을 일컫는 말  
• 개방폐쇄의 원칙 (OCP)
• 객체는 개방에는 열려있고 수정에는 닫혀있어야한다.

2. 추상 팩토리 패턴 

• 팩토리: 객체생성을 담당하는 추상 클래스   
• 관련된 객체 생성의 인터페이스를 제공하되, 생성되는 객체의 구체적인 클래스는 알 알 필요가 없다는 것이다.  

피자스토어에서 여러개의 피자를 구성하는 것을 예로 들어 설명한다.  [그림1]에서 볼 수 있듯이 피자가게에서는 다양한 피자(치즈피자 ,페퍼로니 피자)등을 만들수 있다.  

• NaivePizzaStore 은 NaivePizza를 사용하게 되며, 전적으로 NaivePizza가 상속하는 자시클래스생성에 의존적이게 된다. 의존성은 NaivePizzaStore의 확장성과 수정을 요구하게 되는 상황에 이르게 된다. 

[그림1]  

[그림1]의 의존성을 낮추기 위해서는 , NaviePizzaStore에 하나의 클래스를 연관시켜 피자가게와 피자객체의 의존성을 낮출 수 있다. [그림2]에서 그 의존성 낮춘예로 수정할 수 있다.

• 피자의 객체의 생성을 전적으로 simpleFactory에서 담당하게 만듦으로 pizzaStore의 클래스를 수정할 필요가 없어지며, simple에서 다양한 피자객체와 연관시킬수 있는 확장력을 얻었다. 
• 하지만 피자스토어가 하나가 아니라면 두개의 다른 영역을 가지게 되는 피자가게가 하나 더 생기게 된다면, simple Factory가 복잡하게 구성되어진다.  

[그림2]

[그림2]의 다수의 피자가게에 피자 객체 확장 문제점을 [그림3]에서 해결한것이다. 피자가게가 피자객체를 사용한다는 의존관계를 역의존관계로 느슨하게 결합하도록 제공한다.

• 왜 심플 팩토리는 안되는가?
• 다수의 피자가게가 심플팩토리에서 확인과정을 거쳐야 하며(어떤 피자가게인지, 어떤 피자를 생성해 줘야 하는지) 생성될 수 있는 객첵조건을 다 만들어 줘야 하기 때문에,  심플팩토리는 무거워지며, 수정할 부분이 많아지게 된다. 
• 심플팩토리를 왜 만들었는가?
• 이제 다시 , 원점으로 돌아가서 심플팩토리를 왜 만들어 주었는가 생각해보자, 의존성 때문이었다라고 말한다면 , 그것이 정답이다. 그렇다면 피자 스토어를 상속하는 다른 다수의 피자스토어를 만들어보고, 피자객체를 상속하는 다수의 피자 객체를 어떻게 연관시켜야하는가? 이 의존성을 어떻게 하면 없앨수 있는가? 이렇게 나온것이 역의존관게이다.   
• 어떻게 역 의존하게 만드는가?
• 피자객체에서 팩토리 객체를(다른피자 객체 ) 파라미터나 레퍼런스로 받아, 그 객체를 이용하여 실행되는 피자 객체를 생성한다. 마치 피자 객체가 수행되는것 같지만 내부적으로 팩토리가 실행된다.
• ex) new CheesePizza(Factoty fac){ fac.createCheese()} 이 코드와 같이 실질적으로 cheesePizza의 객체가 실행되지만, 실질적 내부는 팩토리 함수가 실행된다. 이와 같은 방식을 의존성 역전이 되었다고한다

[그림3]

• 의존성 역전의 장점은 무엇인가?
• 피자 객체를 수정할 필요없이, 팩토리에 수정과 추가로 확장이 가능하며, 다양한 피자의 조합을 피자가게에 적용할 수 있게 된다. 

3. 팩토리 패턴의 장점 및 단점

• 생성할 클래스가 변하면, 메서드 ,인터페이스 전체를 바꾸어야한다.
• 다수의 클래스, 상황에 맞는 클래스 생성 시 적합하다.
• 객체 생성을 위한 인스턴스를 생성하지 않아도 된다. 

* 참고 및 출처

 - http://warmz.tistory.com/entry/Abstract-Factory-Pattern-%EC%B6%94%EC%83%81-%ED%8C%A9%ED%86%A0%EB%A6%AC-%ED%8C%A8%ED%84%B4