Rise Up

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

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

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

아직 잘 모르시겠다구요?

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

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

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

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

 

[ 이 포스팅의 내용은 한빛미디어의 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 라를 클래스를 상속받아 여러가지 오리를 만들고,
오리의 행동에 대해서 인터페이스를 만들고 여러 클래스에 구현하여 상속 받고 그 행동들을 각각에 오리에 집어 넣어준 -_-;
블로그 시작 초기라서 아직은 표현이 많이 부족합니다. ㅠㅠ