각 상태 정보를 클래스화해서 상태에 따른 행동을 만들어 놓는 것

=> 상태에 따라 행위를 변경해야 할때

일반적 관리를 위해 ABC 가 필요

멀티 쓰레드에서도 유리

각 상태를 나타내는 클래스들이 데이터 멤버를 가지지 않는다면 이들은 공유될 수 있다

객체 내부에 데이터 멤버가 없으면 객체는 동일한상태 ==> 서로간의 구분이 필요 없음

공유는 Flyweight , 또는 singleton 으로 구현 가능

(구조는 Flyweight 와 singleton 이 유사하다)

상태전환(객체를 누가 바꿀 것인가)

1. 클라이언트가  기준에 의해서 상태를 바꿔주는 것

    상태 전환 표에 따라 변환되게 할 수 있지만 , 새로운 상태가 추가 되면 상태표를 다시 고처줘야 한다

    상태객체관리가 보다 쉽다(상태 객체 추가 정도만 하면 되므로)

2. 각 상태 객체에서 각 상태가 끝나면 상태 객체에서 다음 상태를 반환

   이때는 각 상태간의 상태를 알아야 하는 상황이 올 수 있으므로 다른 상태 클래스를 추가할 경우 기존 것을 고처야 할 수 도 있다

   대략 mediator , observer 패턴을 연동해본느 것도 아이디어일 수 있다

둘다 장단점이 있음

상태 객체 삭제:

1. 상태가 공유되는 경우 공유되는 객체에 대한 레퍼런스 카운트를 두어 참조하는 객체가 없으면 소거한다

2. 필요 없는 상태객체 삭제 => A 객체에서 B 객체 즉 A 상태에서 B 상태로 갈때 A 의 포인터를 가지고 있는

    statepointer 를 delete statepointer ; 한 후  B 를  statepointer = new B 한다

    상태변환이 적은 경우 유용

10000명의 플레이어가 있다

캐릭터의 능력레벨이 20단계로 나뉘어진다고 가정하고 각 레벨마다 사용할 수 있는 것이 다르다고 한다, 하지만 중복되는 상태가 있을 수도 있다고 할대

20 단계 이상의 레벨을 추가 또는 삭제 할 수 있는 설계는?

=> 먼저 레벨들을 클래스로 만든 후, 1명 마다 각각 상태를 갖으면 낭비가 심함으로 공유되는 상태를 위해 Flywieght 패턴을 적용 할 수 있는데

    각 레벨의 특성마다 클래스가 다름으로 능력레벨에 대한 Abstract Base Class 를 두어 하나로 묶은 후 레벨 추가 삭제가 보다 간편해지게 하고

    유저는 상단 클래스의 포인터를 가지고 있으면 보다 효과 적이다

공유한다는 것은 각 레벨 클래스를 한번만 생성해놓고 다른 것들(다른 플레이어들)이 참조한다는 것

 

 

mediator 와 observer 의 차이는

observer 는 중심이 되는것이 밖에 있는 것들 즉 중계자가 중심이 되는 것이 아니고

중계자가 아닌 밖의 옵저버들이 대한 변경 사항을 subject(중계자) 에게 알리면 변경사항을 나머지 옵저버들에게 알려주는 것이

Observer pattern

A 의 오브젝트 변경사항을 나머지에도 적용 시키는 패턴

중간에 Subject 가 이를 반영한다

원래 처음 주어진 환경이 이런 환경

A(observer object) 에서 변경된 부분을  Subject  에게 전달해주고

Subject 는 A 가 업데이트 됐다면 Subject 가 A 에서 읽어와 나머지 오브젝트들(observer objects)에게 변경사항을 알려주는 것

switch 를 피하기 위해 동일한 인터페이스 사용

subject 클래스는 내부적으로 observer objects 를 리스트로 관리할뿐 구체적으로 어떤 observer object 들인지는 관여하지 않는다

=> 즉 동일한 인터페이스를 갖는다

서로 업데이트 하려고 하는 경우 같은 정보로 변경할 경우 subject 에서 정볼르 받아 쌓아놨다가 이전에 바꿨던것과 동일한가를 비교

이렇게 알려주려면 알려주기 위한 클래스를 생성 해야 한다

subject 가다른 observer objects 와 동일한 데이터 일경우 싱글톤으로 만들 수도 있다

subject 가 여러개가 있고 observer 가 여러개 있을 수 있다

업데이트시 this  를 넘겨줌

subject 가 소멸되는 경우 각 observer objects 들은 소멸 하거나 어떤 처리를 해야 함

setstate() 함수 호출의 순서를 조절할 수 있는 것이 themplate method 패턴을 참고

=> subject 에서 값변환 먼저 실행후 notify 실행, 각 옵저버 객체에서도 동일하게 추가 되야 함

-특정 값이 바뀌었을때는 subject 에 클래스를 미리 등록 시켜 놓고 관심 있는 옵저버 클래스에게만 알려 효율 올림

-

오브젝트 N 개 서브젝트 M 개 일때

중간에 change manager 를 두고 이 사이를 관리할 수도 있음

change manager 를 상속 받는 manager 의 종류를 또 분류하여, 변경사항을 다 통보해주는 매니저로 갈지

변경사항이 연관있는 옵저버오브젝트들에게만 알릴지를 정할 수도 있다( 전자의 경우 mediator 와 유사)

한 노드가  subject 와 observer 역할을 둘다 할 수도 있다

옵저버가 다른 옵저버와 연결 되는 경우

1. 다중상속

2. 다중상속이 힘든 환경이면 subject ,observer 클래스를 따로 구현 하지 않고 하나로 두어 구현

스트크래프트 미니 맵에서 적은 안보이고 우리만 보이는 상황

전체 오브젝트에 대해서 서브젝트가 가지고 있는데

Subject 에서 A편, B 편, 관람자들의 리스트를 따로 가지고 있어서

연관된 사람들에게만 오브젝트 위치를 보여준다

상태정보 저장이 목적

undo, redo 같은 기능을 실행 하기 위해선 변경된 정보 , 심할 경우 변경된 상태의 전체 정보를

따로 저장 관리하는 클래스를 두는 것을 memento 패턴이라 한다

일반적으로 필요한 정보만 따로 모아 관리 하는 것을 말한다

행동:

저장할 필요 정보를 memento 에 저장했다가 다시 돌리고 싶을때 memento 에서 다시 불러온다

또한 해당 객체 상태를 직접 접근하는 것이 어려운 경우 상태 정보를 memento 로 빼놓아

클라이언트가 객체의 은닉성을 깨트리지 않고 상태 정보를 알기 위해 memento 로 저근하는 상황에서도 사용 될 수 있다

이처럼 직접 접근하지 못하게 경계 역할도 할 수 있다

하지만 원래 memento 에 상태를 저장하는 객체는 memento 객체를 마음대로 다루길 원함으로

friend 로 선언해 주는 것도 좋다

하지만 다른 것이 접근할때는 private 로 선언하는게 좋다

모든 값을 다 저장해서 가지고 있으면 비효율적이므로 변경된 부분만 관리 한다( 이부분 설계가 관건)

지나치게 memento 에 다른 클라이언트가 접근해 모두 막 상태를 바꾸는 구조는 좋지 않다

redo/undo 같은 경우  메모리가 많이 커질 수 있음으로 횟수의 제한을 두는 것이 좋다

command 패턴과 memento 패턴을 같이 사용하여 명령을 memento 에 저장해 놓으면 효과적이다

memento 할(저장할) 단위 설정이 중요

단위가너무 작으면 저장된는 것이 많아 질 수 있다

 

 

예를들어 list 의 경우

list 내부에 포인터를 두면 멀티플(멀티 쓰레드)로 list 에 접근할때 오류가 생길 수 있는데

이것을 객체로 두면 멀티플로 접근이 가능해진다

즉 접근 포인터를 객체로 둔것이 iterator 패턴이다

굳이 필요한 상황 아니면 type<T>::iterator it; 쓰는게 났다

리스트자체에서 리스트에 대한 이터레이터를 만들때의 구현

( iterator 가 없어질때 List 를 동적 또는 정적 할당 하지 않았음으로 삭제 과정은 필요 없고 new 한 Listiterator 만 삭제 하면 된다

pListiter 으로 함수 안에서 생성된 list 를 다룰 수 있다

ListIterator* pListiter = list.createiterator();

했을때..

       iterater* createiterator(){

            return new ListIterator(this);   // this 는 리스트의 주소

       }

class ListIterator: public Iterator {
  public :
    ListIterator(LinkedList* pList){  this->pList = pList;  }

  private :
    LinkedList* pList_;
};

 

 

문법에 대한 패턴, 간단한 연산 등 간단한 스크립트 같은거나 간단한 정규식 그리고 비교적 작은 형태일때

속도가 안중요할때 쓰임

처리 영역을 나누지 않고 한번에 처리할때

복잡한 경우에는 다루기 힘들다

interpreter 패턴은 파싱을 하지 않고 바로 객구조를 만들어 사용

interpreter 패턴에 멤버  함수를 정의하는 것이 번거로운 경우 vistor 패턴을 각 연산마다 적용하여

추상노드를 순회하도록함으로써 interpreter 패턴의 수행역할을 동일하게 할 수 있다

장점 : 문법에서 클래스 구조를 만들어 내고 만들어진 클래스 구조를 보고 다시 문법을 봐 성립하면 이것이 맞는 구조라 할 수 있음

 XML DTD 문법이 맞는지 체크하라

즉 간단한 문법이 있는데 이것을 프로그램으로 읽어 들였을때 맞는 것인지 확인

<!Element purchaseOrder (shipTo,BilTo,Item) >

<!Element shipTo (Name,Street,city,state,country,zip) >

<!Element BilTo (Name,Street,city,state,country,zip) >

<!Element Item (ProductNo,quentity, price, ItemName,orderDate) >

<!Element Name (#PCdate) >

위는 아래와 같다

purchaseOrder := shipTo & BilTo & Item +

shipTo := Name & Street .. 이런식

+ 는 한번이상 나타난다

* 는 0번 이상 나타난다

purchaseOrder,shipTo  왼쪽에 나타나는개 클래스 

XML 이 문법을 만드는 것인데 이 문법이 맞는것인지 아닌지를 확인 할때 interpreter 패턴을 사용 할 수 있다

클래스 구조적 포인트는

연산자이든, 문자열이든 동일한 부모 추상클래스를 두어서 실행시키는 함수를 virtual 로 정의해놓고 이 함수를

수행하는 것

즉 연산자와, 문자를 파싱할때 동일한 부모이니 연산자이든 문자이든 동일한 타입의 부모로 캐스팅 됨을 이용하여

보다 간결한 구조로 조사와 순회 할 수 있다는 것

 

 

command 패턴이란?

요청과 이 요청을 처리할 객체를 중계하기 위한 클래스 상속구조를 말한다

여라가지의 처리할 명령을 'A' 에서 요청할 경우 'A'쪽의 명령들을

Abstract Base class 기반으로 구성하여 각 명령에 대해 처리할 관련있는 클래스들끼리 참조 또는 할당하여 하나의 객체로 구성하여

map 등으로 명령과 클래스를 같이 갖고 있는 형태로 만들어 놓은후

B 쪽에서 이것을 처리할때

A 에서 만든 상속구조처럼 묶어 처리하는 패턴

오고 가는 것은 map 의 value 가 오고 가지만 이 value 에 대한 명령 처리를

B쪽에서는 해당 처리해야 할 서브 클래스에 대한 해당 명렬을 처리할 클래스를 추출해 낼 수 있음으로

이 둘의 연결 구조를 보다 각각의 지역적으로 분할된 형태로 처리 할 수 있다

2. callback 버튼 실행 명령 함수에 이를 대입할 수 있다

  C 함수는 괜찮은데 , 멤버 함수를 callback 으로 부를 경우 문제가 될 수 있는데 이때 사용 할 수 있다

3. redo, undo 에 적용 하기 쉽다

  각 명령에 대해서 동일한 인터페이스로 처리 가능

  즉 동일한 데이터 타입으로 명령을 처리 할 수 있고 필요 한 클래스들만 있으면 된다

  => 동일한 데이터만 핸들링 하면 된다

 undo/redo 의 순서는 memento 패턴으로 해결 하면 된다

또한 undo/redo 의 객체 상태 저장은 prototype패턴 or 바뀐부분을 저장하는 방법 memento 패턴을 활용(상태 값을 저장해 놓는 형태)

*undo/redo 는 연산을 했던걸 다시 역으로 하는 것보단, 상태값으로 그때의 상태를 제연하는 것이 좋다

4. protocal 과 같은 명령에 대한 처리에도 유용하다

5. makefunctor( (functor1*), ai, show );   <= 표기 정확하지 않음 대략적으로 표기

같은 것 또한 전역 함수나, 멤버함수를 동일한 형태로써 두개를 수행 할 수 있는 것과 같은 것도 command 패턴의 유형과 개념상 비슷하다고 볼 수 있다

명령종류의 자체가 많아 지면 command 들의 상위인 command 클래스가 필요한데 이렇게 명령의 종류가 많아지면

composite 패턴과 연동하여 한번에 처리 할 수 있게 한다

동일한 레벨을 묶고 있는게 composite 이니깐 동일하게 묶고 있는것에 대해 전체를  돌면서 다 실행하는 virtual 함수 실행

명령의 종류에 대해 나뉘어지는 형태이므로

다른 유사 명령과 교체하여 실행을 다르게 설정 할 수 도 있다

또한 복합적인 명령을 수행해야 하는 경우

서브 command 클래스를 만들 필요 없이

중간에 macrocommand 클래스를 만들어 두어 이 클래스에서 명령을 조합해 실행하는 클래스를 두는 것이 효과적이다

macrocommand 클래스를 활용할 경우 스크립트의 작업형태도 처리 가능하다

execute( ) 의 수행함수에서 인자를 줄려면 다 주던지 안주려면 다 안주던지 해야 한다

함수에 인자가 들어가면 인자타입이 다 틀려지고 부르는 쪽도 맞춰 틀려져야 하기 때문에 처리가 복잡해 진다

각 명령에 대해 한 클래스들이 명령을 처리할 클래스들을 생성자의 초기 값으로 넘겨주게 된다

이때의 생성자 초기 값은 상관 없음으로 명령을 수행할 execute() 함수만 불러주면 되기 때문

 여러 오브젝트가 있을때 현재 자신이 처리할 수 있으면 처리를 하고 끝내지만 현재 자신이 처리하지 못하면

다음 오브젝트로 일을 보내 처리하도록 한다

흐름적 이점 : switch  구문을 제거 할 수 있다

한 프로젝트의 도움말에 대한 사항을 분기문이 아닌 chain of responsibility  패턴으로 처리할 사항을 다음 클래스로 넘기며 처리 할 수 있는데

A, B ,C ,D, E, .... N 의 클래스가 있을때

 A 에서 처리할 수 있는 도움말이면 A 에서 처리 하지만 A 에서 처리 할 수 다음 포인터 주소를 통해 다음 클래스로

처리를 넘긴다

A                  

success() --------------->B

                                         success()--------------->C

                                                                                 success()---------------->

DNS 처리 또한 유사하게 처리 될 수 있다

단 처리 됐는지 처리 되지 않았는지 처리를 넘긴 다음에는 알지 못한다

즉 정확히 어떤 객체가 처리하는지 모른다

도움말, 프린트, 응용프로그램 등등에 대한 각 가지 다양한 종류에 대한 처리 사항을 클라이언트가 요청 할 수 있는데

그때는 요청의 종류 req->GetRequestofKind() 와 같은 종류를 구분 할 수도 있지만 좀 더 나은 방법은

Dynamic_cast 로 현재 넘어온 클래스가 어느 부류에 속하는 클래스인지 다운캐스팅 테스트를 해보아

Dynamic_cast  가 0 을 리턴하면 현재 상속구조의 클래스가 아님으로 다음 분기문에서 다시 다른 종류에 대한 클래스의 다운 캐스팅을

시도해보아 맞을때까지 분기문을 놓는 식으로 처리 한다

패턴을 오히려 너무 많이 남발하면 좋지 않다

적시 적소에 쓸 수 있어야 한다 chain of responsibility 패턴 과 쓰일 수 있는데

다음 노드로 넘어가야 하느냐 말아야 하느냐가 각 노드마다 공통인 부분이기 때문에 이 부분에 대해서 Template Method 패턴이 쓰일 수 있다

다음 으로 넘어가지 않는다고 하면 Template Method 를 지나쳐 다음을 수행 하면 되기 때문..

Template method 패턴이

 

 

기본 변하지 않는 클래스의 계층 구조에서 변하는 부분의 클래스의 추가, 정의 등이 필요할때

기존 구조를 거의 무너트리지 않고 변하는 부분을 만들 수 있는데 그것을 스트레티지 패턴이라 한다

point 는 포함 관계로 변화되는 클래스를 변하지 안흔 클래스의 부모에 포함 시켜서

클래슬르 만들때 원하는 행동의 클래스를 업케스팅해주면 된다

또한 기존에 돌아 가고 있던 행동을 쉽게 교체 하기 위해서도 많이 쓰인다

http://tongins.blog.me/80096279721

[패턴] Strategy Pattern   http://tongins.blog.me/80096279721