Rise Up

우분투 11.04에 크롬 버전입니다 ㅠㅠ

public class PizzaStore { SimplePizzaFactory factory; public PizzaStore(SimplePizzaFactory factory) { this.factory = factory; } public Pizza orderPizza(String type) { Pizza pizza; pizza = factory.createPizza(type); pizza.prepare(); pizza.bake(); pizza.cut(); pizza.box(); return pizza; } }

일단 해보진 않았고 아이폰에서 압축하는 법을 알아내서 올려요.
폰에서 빌드한 결과 잘 돌아가네요.
유용하게 사용하세요!
 

 팩토리 메소드 패턴에서는 객체를 생성하기 위한 인터페이스를 정의하는데, 어던 클래스의 인스턴스를 만드는 일을 서브클레스에서 결정하게 만듭니다. 팩토리 메소드 패턴을 이용하면 클래스의 인스턴스를 만드는 일을 서브클래스에 맡기는 것이다.

이전 팩토리 패턴 1은 주체가 팩토리 객체를 이용해 새로운 객체들을 만들어 냈으나, 팩토리 메소드 패턴은 서브클래스에 의해 생성되는 객체의 클래스가 결정되는 것이다.

 유용한 것은 제품을 생산하는 부분과 제품을 사용하는 부분을 분리할 수 있다는 것이다.
 그리고 Creator에서 추상메소드(여기서는 구상클래스를 구현하는 부분이다.)를 선언하고 각각의 객체를 만드는 것이 Creator를 상속받은 ConcreateCreator를 사용하므로 어떤 객체를 만들 것인가를 각 분점에서 판단하므로 팩토리 패턴 1과는 분명한 차이가 있다.

아직 잘 모르시겠다구요?

팩토리 메소드 패턴이 간단한 팩토리와 상당히 비슷한 것은 맞지만 간단한 팩토리는 일회용 처방에 불과한 반면, 팩토리 메소드 페턴을 이용하면 어떤 구현을 사용할지를 서브클래스에서 경정하는 프레임워크를 만들 수 있다는 점이다. 

-> 새로운 종류의 생산물이 필요할 때 ConcreateProduct와 ConcreateCreator를 만들고 나머지는 실행부에서 주문받은데로 이루어지게 만들면 되는 것이다.

마지막으로 팩토리 메소드 패턴을 정리하자면,

추상 메소드를 이용하고, 상속받은 클래스들이 그 추상 메소드를 구현하고 그에 맞게 상품을 만들어서 사용한다. 팩토리 패턴과 다른 것은 분점의 타이밍을 한 타이밍 뒤(상속받은 하위 클래스)로 둠으로 코드의 유지 보수 및 확장이 뛰어난 것이다.

 

[Head First Design Patterns을 참고했습니다. 저작권에 걸린다면 삭제하겠습니다.]

예를들어 피자집에서 피자 클래스를 상속받아 나머지 피자들을 구현할 경우 new를 이용한 구상 클래스 때문에 코드를 재수정 해야하는 부분이 상당히 존재한다.
피자의 이름이 바뀐다거나, 새로운 종류가 추가되거나, 잘 안팔리는 종류를 메뉴에서 삭제가 되는 경우도 그 예로 들 수 있다.
주로 if - else if -else나 switch로 처리를 할 것이다.

그런경우 구상 클래스 구현 부분을 캡슐화 시키고 Factory라는 한 클래스를 사용하면 된다? 
->그럼 Factory 안에다 그 코드를 옮겨서 캡슐화만 했을 뿐 따로 달라지는 내용이 없다?
->-> 전화 주문, 매장 주문, 인터넷 주문, ARS 주문 등 4가지 주문에서 들어가는 코드를 각각에서 모두 수정할 필요 없이 Factory에서만 수정하면 된다. 

다음은 팩토리 패턴이 피자집 클래스이다.

public class PizzaStore {
	SimplePizzaFactory factory;
 	public PizzaStore(SimplePizzaFactory factory) {
 		this.factory = factory;
	} 
	public Pizza orderPizza(String type) {
		Pizza pizza;
 		pizza = factory.createPizza(type);
 		pizza.prepare();
		pizza.bake();
		pizza.cut();
		pizza.box();
		return pizza;	}
}

객체를 생성하는데 구상 클래스(new)를 사용하지 않고 팩토리에 type을 전달해 주는 형식.
물론 createPizza 메서드 안에는 구상클래스 구현부분이 들어간다 

그럼 왜 이제 Factory 패턴인지 이해가 될 것이다. 피자집에서는 피자를 팔기위해서는 피자를 만들어야 하는데 이 피자를 만드는 부분을 SimplePizzaFactory 클래스인 factory 객체가 만드는 것이다. 바로 피자 공장인 것이다.


 

[이 글은 Head First Design Patterns을 공부하면서 작성한 포스팅이라 책의 내용과 유사한 부분이 상당히 많이 있습니다. 저작권에 걸린다면 바로 삭제하겠습니다.]

 데코레이터 패턴은 객체에 추가적인 요건을 동적으로 첨가한다. 데코레이터는 서브클래스를 만드는 것을 통해서 기능을 유연하게 확장할 수 있는 방식을 제공한다 
라고 서술 하고 있습니다.

 어떻게 보면 객체지향의 확장성에 대해서 제대로 제시하는 디자인 패턴이 아닌가 싶다.

 클래스는 확장에 대해서는 열려 있어야 하지만 코드 변경에 대해서는 닫혀 있어야 한다. 

 기존 코드는 건드리지 않은 채로 확장을 통해서 새로운 행동을 간단하게 추가할 수 있도록 하는게, 과연 가능하단 말인가? 객체는 어떻게 골라야 하지? 

 이 책에서는 모순된 말 같지만 직접 코드를 수정하지 않고도 코드를 확장할 수 있는 기법이 있다고 한다.
 알아보자!

포스팅의 제목이 Decorate Pattern이다. Decorate라는 것은 장식하다! 라는 뜻이다. 

객체안에 상속 쪽으로 넣지 않고 장식을 하면 코드의 수정없이 클래스에 날개를 달 수도, 다리를 달 수도 있다.
 
책에서 말하는 것은 커피를 주문 할 때, 휘핑크림 추가와 모카추가라고 했을 때!
보통은 커피 클래스안에 휘핑크림의 요소와 모카의 요소를 넣기 마련이다.

그러나 데코레이터 패턴은 휘핑크림 클래스 안에, 모카클래스를 넣고, 모카 클래스 안에 커피 클래스를 넣는 방법이다.

결국, 휘핑크림도 음료수 클래스를 상속 받아 만드는 것이고, 모카도 음료수클래스를 상속 받아 만들고, 커피도 음료수를 상속받아 만들면 되는 것.

Beverage beverage1 = new Coffee();

beverage1 = new WhipCream(beverage1);

beverage1 = new Mocha(beverage1);

이런식으로 구현을 하면 결국 beverage1이 모든 것을 갖고 있는! 

 확장성을 위해서 사용하는 것이 아니라면 상당히 오버해드가 커질 수도 있고, 할게 많아지는 것같다.

물론 많이 유명한 팩토리와 빌더 디자인 패턴도 있지만,
한 걸음, 한걸음 나아가 보자고요!

근데, 객체의 class 종류로 이게 커피인지, 물인지 알 수 없다는 단점이 있다. 커피를 할인하는 경우도 그와 같은 경우에 들어가겠죠?

예를들어 커피에 휘핑크림은 무료고, 다른 음료의 휘핑크림은 유료일 때, 코드의 수정을 피할 수 없다. 그럼 if나 switch를 사용해서 나눠야 하고, 유지보수가 힘들어진다는 단점이 있다. 

 

[ 이 포스팅의 내용은 한빛미디어의 head first Design Pattern의 내용을 참고했습니다.]

옵저버 패턴은 여러 디자인 패턴 책에 꼭 나오는, 보통은 앞쪽에 나오는,
디자인 패턴 중의 하나이다.

나 역시 그 옵저버 패턴을 처음으로 구현해 보았는데 처음에는 이해하기 힘들었으나, 계속 계속 보니 하나하나 이해가 되기 시작했다.

 엄, 각각의 옵저버들은 하나의 Subject 객체를 공유하는 것.
 그리고, notify에서 그 Subject 객체가 가지고 있는 옵저버들을 모두 검사해 주면 끝;

  

 [한빛미디어 head first Design Pattern을 참고로 진행합니다]
 정식으로 독학한 첫번째 디자인 패턴

Strategy Pattern : 알고리즘군을 정의하고 각각을 캡슐화하여 교환해서 사용할 수 있도록 만든다. 스트래티지를 활용하면 알고리즘을 사용하는 클라이언트와는 독립적으로 알고리즘을 변경할 수 있다.

대강의 필요성은 상속과 캡슐화가 객체지향 프로그램의 전부라고 생각하는 사람에게 좋다.
예를들어 shape라는 객체를 만든다고 할때, shape를 상속받은 RoundRect, Rect 등 shape를 상속받은 클래스만 해도 꽤나 많을 것이다.

근데 shape에서는 물체의 이동을 추상형으로 선언하였고,
나머지 shape를 상속받은 클래스 들에서는 실제 그 메서드들을 구성했다고 했을 때,
shape의 이동 방법이나 알고리즘이 바뀐다면, 

shape 클래스를 제외한 shape를 상속받은 모든 객체에 대해서 알고리즘을 수정해 주어야 한다.

여러군대에서 수정이 일어나게 되는데, 이것은 프로그래머가 유지, 보수, 확장 하기가 어렵다는 뜻이 된다. 그만큼 버그도 많아질 수 있다.

이럴 때, 쉽게 말해 행동에 대해서 인터페이스를 선언하고, 그 인터페이스가 구현된 클래스들을 shape 클래스 안에 넣어주게 된다.

즉 클라이언트와 독립적으로 알고리즘을 변경할 수 있다. 에서 클라이언트는 shape를 상속 받은 클래스라고 하면 되려나?

아래 파일은 역대 최강 헤드퍼스트의 예제 파일이다.
다음 예제에서는 Duck 라를 클래스를 상속받아 여러가지 오리를 만들고,
오리의 행동에 대해서 인터페이스를 만들고 여러 클래스에 구현하여 상속 받고 그 행동들을 각각에 오리에 집어 넣어준 -_-;
블로그 시작 초기라서 아직은 표현이 많이 부족합니다. ㅠㅠ

 

 상상나래(WPF 기반 프리젠테이션 프로그램, 2011년 04-06까지 삼성소프트웨어 멤버십 창의과제로 진행)를 개발할 때 가장 힘들었던 점이 바로 Object-Oriented Analysis & Design 이었다.
절차지향만 하다가 객체지향을 처음 들어오게 되니, 접근을 어떻게 해야하는지, 구조를 짜는 방법 부터가 너무나 색다르고, 프로젝트의 규모도 큰 편이라 상당한 고민을 했었다.

 그러다 static 변수의 장점만 보고 static을 살짝(?) 남발했다.
 다 짜 놓으니 static 을 볼 때마다 왜이리 쪽팔린지,

 그런데 써야 할 때는 static을 쓰는 것이 맞다.

한빛미디어에서 나온 '뇌를 자극하는 c++'책을 보면
클래스 자체에 관련된 정보라든지 전체 객체와 관련된 정보를 보관하고 다루는데, 사용하라고 나와있다.
예를들어 지금까지 생성한 전체 객체의 수를 관리하는 멤버 변수와 멤버 함수, 혹은 모든 객체가 공통적으로 참조해야하는 정보나 그 정보를 관리하는 함수.

다시한번 예를 들면,
모든 객체를 학생이라고 하면,
학생들이 공통적으로 사용하는 청소도구, 출입구 등은 모든 학생들이 똑같이 공유해야하므로 정적 맴버로 선언해야 한다고 나와있다.

후자의 예는 조금 어긋난 면도 있는 것 같지만, 아무튼 static은 적절할 때 사용해야 합니다