데코레이터 패턴.

메인 객체에 각기 더 올리고자 하는 객체들을 덧 씌워서 그 결과를 나타낸다.

쉽게 생각하면 커피를 떠올리면 된다.

에스프레소에 우유를 넣고 모카를 넣고 원하는 취향대로 하면 하나의 제품이 나온다.

특징이라고 하면 한 객체를 여러 데코레이터들로 감쌀 수 있다는 것과

자신이 장식한 객체에 어떤 행동을 위임 또는 추가적인 작업을 할 수 있다.

즉 언제든 객체를 감쌀 수가 있기에 프로그램 실행 중 유동적으로 데코레이터를 이용 할 수 있다.

아래는 다이어그램과 샘플 코드 이다.


옵져버 패턴...

말 그대로 감시자다.

그 감시자가 각각의 객체들을 관리하고 매 상황 변화에 따른 정보를 넘겨 줄 수 있다.

즉 하나의 주제에 대하여 1:N 관계를 나타내는 로직에 유용하게 쓸 수가 있다.

헤드 퍼스트 책을 참조한 코드는 이렇다.

날씨에 대한 주체적인 클래스를 중심으로 하여 각각의 상황에 맞는 옵져버를 생성하고 인터페이스 형태로 리스트를 관리하는 방식이다.

팩토리 메소드 패턴.

각기 상황에 적합하게 객체를 대신 생성하는 메소드를 통하여 구현된 팩토리 패턴의 확장형이다.

일반적으로 팩토리 패턴의 경우 상속받은 내용에 대하여 각기 new 키워드를 통하여 객체를 생성하는데

만약 프로그램 구조가 확대대고 할 경우 중개자를 통하여 해당하는 객체를 생성하고

거기에 적합한 작업을 하는데에는 이 구조가 더 적합하다.

샘플 코드는 역시나!! 곰을 주제로 해서 간단히 작성 해 봤다 -_-a

디자인 패턴에 대해 아는 것이 많은 분들이 훈수를 둬 줬으면 좋겠다 ㅠ-ㅠ



Stategy Pattern.

뭐라고 해야 할까..

하나의 기능 집합 상에서 각 모듈마다 행동을 따로 하기에 괜찮은 패턴인듯?

쉽게 말하면 백곰 흑곰이 있는데 백곰 움직임이랑 흑곰 움직임이랑 다르다고 가정하고

곰이라는 공통 특성에서 종별의 움직임이 다르게 나타내게 한다 뭐 그런?

(전문 용어로 말하자면 알고리즘 덩어리를 각기 캡슐화 하여 그 알고리즘을 교환 하면서 프로그램을 동작 시킨다.)

흑곰과 백곰은 곰이라는 클래스를 상속받아 각기 기능을 재정의 한다면 코드 줄 수만 들어난다.

하지만 행동에 대한 집합을 새로이 정의 하고 각 메세지 마다 움직이게 행동 한다면 모듈화에 더 좋지 않을까 싶다.

허접한 예제 이지만 예제를 첨부한다.

혼자 공부하던 것들 기억이 새록 새록 나는 듯.. ㅠ_ㅠ


템플릿 메소드 패턴..

간단히 정리하면 다음과 같았다

알고리즘의 일부를 서브 클래스에서 구성하는 것.

상위에서 구성되어있는 일부를 하위에서 의존적으로 구성한다..

라는 뜻인 것 같다.

고정적으로 구현되어 있는 알고리즘에 서브에서 기존의 내용을 오버라이딩하면서

또 다른 결과물을 얻는 것이 편한 것 같기는 한데..

구성이 아닌 상속에 의한 의존도가 너무 쎄다..

하지만 프레임워크 작성에는 도움이 될 것 같다.


MVC..

Model View Controler...

전체적인 흐름은 다음과 같다

View에서 사용자들이 조작을 하면 Controler에서 Model에게 작업을 요청하고

View의 화면 전환이 일어나면서 Model에서는 처리 결과를 View에게 전달한다.

실제 Main 부분을 쓸때

Model 객체를 먼저 생성하고 Controler의 생성자에 대한 인자로 그 객체를 넘겨 이용한다.

이게 전반적인 흐름에 대한 설명이다 -_-..
(사실 회사에서 잠시 본 내용을 정리하는 거라서; 내용이 짧다;;)

Model에 observerPattern을 적용시킨다면 좋은 이점이 생긴다.

한 Model에서 서로 다른 View를 이용할 뿐 아니라 여러 View를 동시에 사용이 가능하다.

MVC에서 각각의 내부 Pattern Login은 다음과 같은 방법을 이용한다.

Model - 옵저버 Pattern

View - 컴포지트 Pattern

Controler - 스트래티지 Pattern

여기까지 작은 주절 거림 ^_^ 나중에 좀 더 자세한 내용을 적어야지..