Design Pattern
- Strategy Pattern 2013.08.12
- abstract factory pattern 2013.07.09
- facade패턴 2013.07.05
Strategy Pattern
abstract factory pattern
참고 및 출처 ::
- Head First Design Pattern
- http://www.gurubee.net/pages/viewpage.action?pageId=1507401
- http://www.hoons.kr/Lecture/LectureMain.aspx?BoardIdx=50097&kind=62&view=0
- http://goo.gl/zX5yO
* Abstract Factory Pattern (추상 팩토리 패턴)
- 팩토리 : 객체 생성을 처리하는 클래스. - 추상 팩토리 패턴의 본질은 "관련된 객체들의 집단(family)을 생성하는 인터페이스를 제공하되, 생성되는 객체의 구체적인 클래스를 알 필요 없다는 것"이다. - Factory를 사용하는 Client가 많을 경우 여러 클래스에서 사용할 수 있다. - 생성할 클래스가 변하면 인터페이스 메서드 전체를 수정해야 하는 단점이 있으나 다수의 클래스가 존재하고 상황에 맞게 적당한 클래스를 골라서 생성할 때 유용하다. - 객체 생성을 위한 메소드 실행을 위해 객체 인스턴스를 만들지 않아도 된다. |
Abstract Factory Pattern(이하 추상 팩토리 패턴)은 공통의 테마를 가진 팩토리의 그룹을 캡슐화하는 방법을 제공하는 디자인
패턴이다. 일반적으로 클라이언트 소프트웨어는 추상 팩토리의 구체적인 구현체를 생성하고 그 구현체의 인터페이스를 사용한다.
클라이언트는 생성된 객체의 인터페이스만 사용하기 때문에 각각의 내부 팩토리로부터 얻는 구체적인 객체에 대해 알지 못한다.
이 패턴은 어떤 객체들의 그룹에 대한 구체적인 구현을 일반적인 사용법(인터페이스)으로부터 분리시킨다.
* 간단한 팩토리 정의
간단한 피자 팩토리를 만들어 보자.
1. 일반 피자 팩토리
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 | //============================================== //피자 가게 운영을 위한 객체생성 //============================================== Pizza orderPizza() { Pizza pizza = new Pizza(); Pizza.prepare(); Pizza.bake(); Pizza.cut(); Pizza.box(); return pizza; } //============================================== //여러 종류 피자를 만들기 위한 수정 //============================================== Pizza orderPizza(String type){ Pizza pizza; //피자 종류가 바뀔 때 마다 코드를 고쳐야함. if (type.equals( "cheese" )){ pizza = new CheesePizza(); } else if (type.equals( "pepperoni" )){ pizza = new PepperoniPizza(); } else if (type.equals( "clam" )){ pizza = new ClamPizza(); } else if (type.equals( "veggie" )){ pizza = new VeggiePizza(); } //피자 종류에 상관없이 바뀌지 않는 부분. Pizza.prepare(); Pizza.bake(); Pizza.cut(); Pizza.box(); return pizza; } |
2. 간단한 피자 피자 팩토리 (Simple Factory)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 | //============================================== //피자 가게 객체 생성에 캡슐화 적용 //============================================== Pizza orderPizza(String type){ Pizza pizza; Pizza.prepare(); Pizza.bake(); Pizza.cut(); Pizza.box(); return pizza; } //============================================== //피자를 만들기 위한 객체생성 //============================================== public class SimplePizzaFactory{ //클라이언트에서 새로운 객체의 인스턴스를 만들때 호출 public Pizza createPizza (String type){ Pizza pizza = null ; //orderPizza() 메소드에서 뽑아낸 코드(피자의 종류를 결정) if (type.equals( "cheese" )){ pizza = new CheesePizza(); } else if (type.equals( "pepperoni" )){ pizza = new PepperoniPizza(); } else if (type.equals( "clam" )){ pizza = new ClamPizza(); } else if (type.equals( "veggie" )){ pizza = new VeggiePizza(); } return pizza; } } |
간단한 피자 팩토리의 장점은 아래와 같다.
정적 팩토리(Static Factory)
- 장점 : 객체 생성을 위한 메소드 실행을 위해 객체 인스턴스를 만들지 않아도 된다.
- 단점 : 서브 클래스를 만들어 객체 생성 메소드의 행동을 변경 시킬 수 없다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 | //============================================== //팩토리를 이용한 피자 객체를 생성 //============================================== public class PizzaStore{ //Simplepizzafactory에 대한 레퍼런스를 저장 SimplePizzaFactory factory; //PizzaStore의 생성자에 팩토리 객체 전달 public Pizza createPizza (SimplePizzaFactory factory){ this .factory = factory; } public Pizza orderPizza (String type){ Pizza pizza; /*orderPizza() 매소드에서는 팩토리를 써서 피자 객체 생성. new 연산자 대신 팩토리 객체에 있는 create 메소드를 사용. 구상 클래스의 인스턴스를 만들 필요가 없다.*/ pizza = faactory.createPizza(type); Pizza.prepare(); Pizza.bake(); Pizza.cut(); Pizza.box(); return pizza; } } |
피자 가게의 클래스 다이어그램은 아래와 같다.
* 피자가게 프레임워크
문제점이 생겼다. 각 분점마다 독자적인 방법을 사용하기 시작했기 때문이다. 그래서 피자 가게와 피자 제작 과정을 하나로 묶어주는 프레임워크를 만들어야 겠다는 생각에 도달했다. 피자를 만드는 활동 자체는 전부 PizzaStore 클래스에 국한 시키면서도 분점마다 고유의 스타일을 살릴 수 있도록 하는 방법을 적용해보자.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | //============================================== //추상클래스 (PizzaStore) 생성 //============================================== public abstract class PizzaStore { public Pizza orderPizza(String type) { Pizza pizza; //PizzaStore의 createPizza를 호출 pizza = createPizza(type); pizza.prepare(); pizza.bake(); pizza.cut(); pizza.box(); return pizza; } //팩토리 객체대신 사용 abstract createPizza(String type); } |
* Factory Method Pattern (팩토리 메서드 패턴)
정의
객체를 생성하기 위한 인터페이스를 정의하는데, 어떤 클래스의 인스턴스를 만들지는 서브 클래스에서 결정하게 만드는 것.
특징
- 모든 팩토리 패턴에서는 객체 생성을 캡슐화한다.
- 객체 생성 코드를 전부 한 객체 또는 메소드에 집어 넣으면 코드에서 중복되는 내용을 제거할 수 있고, 나중에 관리할 때도 한 군데에만 신경 쓰면 된다.
- 구현이 아닌 인터페이스를 바탕으로 프로그래밍을 할 수 있고, 그 결과 유연성과 확장성이 뛰어난 코드를 만들 수 있게 된다.
* 피자 팩토리 메소드를 이용한 피자 주문
1. PizzaStore 인스턴스 확보
2. orderPizza() 호출
3. createPizza() 호출. (Pizza 객체가 OderPizza() 메소드로 리턴됨)
4. orderPizza() 피자를 준비하고, 굽고, 자르고, 포장하는 작업 완료함.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 | public abstract class Pizza { String name; String dough; String sauce; ArrayList toppings = new ArrayList(); void prepare() { System.out.println( "Preparing " + name); System.out.println( "Tossing dough.." ); System.out.println( "Adding sauce... " ); System.out.println( "Adding toppings: " ); for ( int i= 0 ; i< toppings.size(); i++) { System.out.println( " " + toppings.get(i)); } } void bake() { System.out.println( "Bake for 25 miutes at 350" ); } void cut() { System.out.println( "Cutting the pizza into diagonal slices" ); } void box() { System.out.println( "Place pizza in official PizzaStore box" ); } public String getName() { return name; } } public class NYStyleCheesePizza extends Pizza { public NYStyleCheesePizza() { name = "NY Style Sauce and Cheese Pizza" ; dough = "Thin Crust Dough" ; sauce = "Marinara Sauce" ; toppings.add( "Grated Reggiano Cheese" ); } } public class ChicagoStyleCheesePizza extends Pizza { public ChicagoStyleCheesePizza() { name = "Chicago Style Sauce and Cheese Pizza" ; dough = "Extra Thick Crust Dough" ; sauce = "Plum Tomato Sauce" ; toppings.add( "Shredded Mozzarella Cheese" ); } void cut() { System.out.println( "Cutting the pizza into square slices" ); } } public class PizzaTestDrive { public static void main(String[] args) { PizzaStore nyStore = new NYPizzaStore(); PizzaStore chicagoStore = new ChicagoPizzaStore(); Pizza pizza = nyStore.orderPizza( "cheese" ); System.out.println( "Ethan ordered a " + pizza.getName() + "\n" ); Pizza pizza = chicagoStore.orderPizza( "cheese" ); System.out.println( "Joel ordered a " + pizza.getName() + "\n" ); } } |
* 객체 의존성 살피기
객체 인스턴스를 직접 만들면 구상 클래스에 의존해야 한다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 | public class DependentPizzaStore { public Pizza createPizza(String style, String type) { Pizza pizza = null ; //뉴욕풍 피자를 처리하는 부분 if (style.equals( "NY" )) { if (type.equals( "cheese" )) { pizza = new NYStyleCheesePizza(); } else if (type.equals( "veggie" )) { pizza = new NYStyleVeggiePizza(); } else if (type.equals( "clam" )) { pizza = new NYStyleClamPizza(); } else if (type.equals( "pepperoni" )) { pizza = new NYStylePepperoniPizza(); } //시카고풍 피자를 처리하는 부분 } else if (style.equals( "Chicago" )) { if (type.equals( "cheese" )) { pizza = new ChicagoStyleCheesePizza(); } else if (type.equals( "veggie" )) { pizza = new ChicagoStyleVeggiePizza(); } else if (type.equals( "clam" )) { pizza = new ChicagoStyleClamPizza(); } else if (type.equals( "pepperoni" )) { pizza = new ChicagoStylePepperoniPizza(); } } else { System.out.println( "Error: invalid type of pizza" ); return null ; } pizza.prepare(); pizza.bake(); pizza.cut(); pizza.box(); return pizza; } } |
* 의존성 뒤집기 원칙 (Dependency Inversion Priciple)
- 추상화 된 것에 의존하도록 만들어라. - 구상 클래스에 의존하도록 만들지 말라. |
심하게 의존적인 PizzaStore() 의 가장 큰 문제점은 모든 종류의 피자에 의존한다는 점이다.
- 팩토리 메소드 패턴을 적용하고 나면 고수준 구성요소인 PizzaStore 와 저수준 구성요소인 피자 객체들이 모두 추상 클래스인 Pizza에 의존한다.
- 팩토리 메소드 패턴은 의존성 뒤집기 원칙을 준수하기 위해 쓸 수 있는 가장 적합한 방법 가운데 하나이다.
* 개발자가 지향해야 하는 규칙
- 어떤 변수에도 구상 클래스에 대한 레퍼런스를 저장하지 않는다. - 구상 클래스에서 유도된 클래스를 만들지 않는다. - 베이스 클래스에 이미 구현되어 있던 메소드를 오버라이드 하지 않는다. |
* 원재료 공장 만들기
원재료를 생산할 팩토리를 위한 인터페이스 정의.
모든 팩토리 인스턴스에서 공통적으로 사용하는 부분이 있다면 인터페이스가 아닌 추상클래스로 만들어도 된다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 | public interface PizzaIngredientFactory { //각 재료별로 생성 메소드 정의. public Dough createDough(); public Sauce createSauce(); public Cheese createCheese(); public Veggies[] createVeggies(); public Pepperoni createPepperoni(); public Clams createClam(); } //======================================================================== //모든 재료 공장에서 구현해야 하는 인터페이스를 구현 //======================================================================== public class NYPizzaIngredientFactory implements PizzaIngredientFactory { public Dough createDough() { return new ThinCrustDough(); } public Sauce createSauce() { return new MarinaraSauce(); } public Cheese createCheese() { return new ReggianoCheese(); } public Veggies[] createVeggies() { Veggies veggies[] = { new Garlic(), new Onion(), new Mushroom(), new RedPepper() }; return veggies; } public Pepperoni createPepperoni() { return new SlicedPepperoni(); } public Clams createClam() { return new FreshClams(); } } |
'Design Pattern' 카테고리의 다른 글
Strategy Pattern (0) | 2013.08.12 |
---|---|
facade패턴 (0) | 2013.07.05 |
facade패턴
퍼사드 패턴을 설명하기 앞서 이전의 다른 패턴을 기억해 보자.
패턴
용도
----------------------------------------------------------------------
데코레이터 한
인터페이스를 다른 인터페이스로 변환
어댑터 인터페스는 바꾸지 않고 책임(기능)만 추가
퍼사드 인터페이스를 간단하게 바꿈
1. 컨텍스트
Facade 패턴은 복잡한 서브 시스템에 통일된 인터페이스를 제공함으로써 복잡한 API를 단순화 시켜준다.
시스템을 서브 시스템 단위로 나누어 구성하는 것은 시스템의 복잡도를 낮춰주지만, 동시에 서브 시스템 사이에서의 통신 부하와 결합도가 증가하게
된다. 이러한 서브 시스템 사이의 의존도를 낮추고, 서브 시스템의 사용자 입장에서 사용하기 편리한 인터페이스를 제공하고자 하는 것이 facade
객체이다.
Facade 객체는 실생활에서의 고객 서비스 센터와 유사하다. 가령, 어떤 상품을 구매하는 과정에서 문제가 생겼다고 가정할 때, 고객이
문제의 성격에 따라 해당 부서에 직접 연락하는 것이 아니라 고객 서비스 센터를 통하는 것은 Facade 패턴에 대한 좋은 유추 사례가 될 수
있다.
2. 적용 영역
■ 복잡한 서브 시스템에 대해 간단한 인터페이스를 제공하기를 원하는 경우
■ 클라이언트와
인터페이스의 구현 클래스 사이에 의존도가 높은 경우
■ 서브 시스템을 레이어(layer)로 구분하고자 하는 경우
3.
구조
4. 적용 결과
■ 서브 시스템의 컴포넌트로부터 클라이언트를 격리하여, 클라이언트가 쉽게 서브 시스템을
이용할 수 있다.
■ 서브 시스템과 클라이언트 사이의 의존성을 낮춘다.
■ Facade 패턴을 사용한다고 해도, 필요한 경우 서브
시스템의 클래스에 직접 접근할 수도 있다. 즉, 일반화 정도(generality)와 개발의 편의성 사이에서의 적당한 합의점을 찾아야
한다.
5. 관련 패턴
■ Abstract Factory는 Facade와 함께 사용되어 서브 시스템에 독립적으로 서브
시스템의 객체를 생성하는 인터페이스를 제공한다. 또한, 특정 플랫폼에 국한된 클래스를 숨기기 위해 Facade 대신 사용할 수도 있다.
■
Mediator는 기존의 클래스의 기능을 추상화한다는 의미에서 Facade와 유사하다. 그러나, Mediator의 목적은 서로 직접적인 연관을
갖는 객체(colleague object) 사이에서의 커뮤니케이션을 추상화하는 것인데 반해, Facade는 서브 시스템의 인터페이스를 추상화하는
것이다.
■ 하나의 Facade 객체만이 요구되는 경우에는 Facade 객체가 Singleton 형태를 취하기도 한다.
'Design Pattern' 카테고리의 다른 글
Strategy Pattern (0) | 2013.08.12 |
---|---|
abstract factory pattern (0) | 2013.07.09 |