웃어라 온 세상이 너와 함께 웃을것이다.

Command Processor서비스에 대한 요청과 서비스의 실행을 분리한다.요청을 독립적인 객체로 관리하며 실행을 스케줄링 한다.작업취소에 대비해 요청 객체를 저장하는 추가적인 서비스를 제공한다. 문제사용자들마다 나름의 방식으로 애플리케이션을 다루고 싶어한다.애플리케이션의 확장은 기존에 있던 코드에 영향을 미쳐서는 안 된다.작업취소와 같은 추가 서비스는 모든 요청에 대해서 일관적으로 구현되어야 한다. 해법커맨드 프로세서가 모든 커맨드 개체들을 다룬다.커맨드 프로세서는 명령의 실행을 스케줄링하고 추후에 있을지 모를 작업취소에 대비해 명령을 저장한다. 구조동작 구현추상 커맨드 컴포넌트의 인터페이스를 정의한다.각 유형마다 커맨드 컴포넌트를 설계한다.순차적으로 수행되는 몇몇 명령들을 조합한 매크로 명령을 제공..

Proxy 디자인 패턴은 컴포넌트의 클라이언트로 하여금 컴포넌트 자체가 아니라 컴포넌트의 대리자와 통신하도록 해준다. 이런 위치 보유자는 효율을 향상시키고, 쉽게 엑스스 할 수 있게 해주며 권한을 부여받지 못한 액세스를 방지하는 등의 역활을 할 수 있다. 문제컴포넌트에 액세스하는 작업은 런타임에 효과적이고 비용이 덜 들며 클라이언트와 컴포넌트 모두에 대해 안전해야 한다.컴포넌트에 액세스하는 작업은 클라이언트의 입장에서 투명하고 간단해야 한다. 이 컴포넌트를 호출할 때 사용하는 동작이나 구문이, 직접 액세스할 수 있는 다른 컴포넌트를 호출할 때 사용하는 동작이나 구문과 특별히 다르거나 많이 변경해서는 안 된다. 클라이언트는 원격 클라이언트에 액세스할 경우 일어날 수 있는 성능상 하락이나 비용상 손해에 대해..

Master-Slave - 디자인 패턴은 마스터 컴포터가 자신과 동등한 역활을 하는 Slave에 컴포넌트에 작업을 분산하고, 이 Slave들에서 반환된 결과들로 부터 최종 결과를 계산해내는 패턴이다. 문제.- 클라이언트는 계산이 분할-정복 원칙에 근거하고 있다는 사실을 알 필요가 없다. - 클라이언트나 서브태스크의 처리는 작업을 분할하고 최종 결과를 모으는 알고리즘에 좌우되어서는 안 된다.- 서브태스크들을 처리하기 위해서는 (예를 들어 계산 정확도를 향상시키기 위한 경우처럼) 서로 다르지만 의미적으로 동일한 구현들을 사용하는 것이 좋다. - 서브태스크들을 처리할 때 간혹 조정이 필요하기도 하다. 해법.장애 허용성 – 서비스의 실행을 여러 개의 복제된 구현들에 위임한다. 분할된 서비스의 실행들에 장애가 발..

Whole-Part - 의미적 단위로 컴포넌트를 모으는데 도움을 준다. - Whole 객체(집합 컴포넌트)는 그것을 구성하는 Part(컴포넌트) 객체들을 캡슐화 한다. 문제- 복합 객체는 작은 객체로 분해되거나 기존에 있던 객체들로 구성.- 재사용성, 가변성을 지원하며 객체들을 다른 유형의 집합 객체로 재조합.- 클라이언트는 집합 객체를 자체 구성 부분에 직접 액세스를 허용하지 않는 원자적 개체로 인식. 해법- 더 작은 객체들을 캡슐화하는 컴포넌트를 도입해서, 클라이언트가 컴포넌트의 구성 부분들에 직접 액세스 할 수 없도록 막는다.- 캡슐화된 객체들의 기능에는 직접 액세스할 수 없으며 이 객체들의 기능에 액세스하기 위해서 집합 객체의 인터페이스를 통해야 한다. Whole-Part 패턴의 일반 원칙은 다음..

의도 - 객체를 생성하기 위해 인터페이스를 정의하지만, 어떤 클래스의 인스턴스를 생성할지에 대한 결정은 서브 클래스가 내리도록 한다. 활용 - 어떤 클래스가 자신이 생성해야 하는 객체의 클래스를 예측할 수 없을 때 - 생성할 객체를 기술하는 책임을 자신의 서브클래스가 지정했으면 할 때 - 객체 생성의 책임을 몇 개의 보조 서브클래스 가운데 하나에게 위임하고, 어떤 서브클래스가 위임자인지에 대한 정보를 국소화 시키고 싶을 때

의도 - 복잡한 객체를 생성하는 방법과 표현하는 방법을 정의하는 클래스를 별도로 분리하여, 서로 다른 표현이라도 이를 생성할 수 있는 동일한 절차를 제공할 수 있어야 한다. 패턴 활용 - 복합 객체의 생성 알고리즘이 이를 합성하는 요소 객체들이 무엇인지 이들의 조립 방법에 독립적일 때 - 합성할 객체들의 표현이 서로 다르더라도 생성 절차에서 이를 지원해야 할 때. 결과 - 제품에 대한 내부 표현을 다양하게 변화할 수 있다. - 생성과 표현에 필요한 코드를 분리한다. - 복합 객체를 생성하는 절차를 좀더 세밀하게 나눌 수 있다.

위의 보이는 것은 일반적으로 사용하는 싱클턴의 방법이다. 하지만 이 방법은 Thread-Safe 하지 않다. 그래서 다음과 같이 바꾸었다. 이런식으로 하면 Thread-Safe 하게 된다고 할 수 있다. 하지만 이 방법 역시 무조건 100%확실하다고 할 순 없다. Debug모드에서는 안전하지만 만일 Release모드일때 컴파일러가스스로 최적화를 해버려 Lock에 동시 접근을 하는 경우가 극히 드물게 나타난다는 전설을... 위의 코드를 테스트는 엄청난 귀찮음이 엄습하는 관계로. 이렇게 Thread 1개 만들고, 100만번 돌려보는 것만으로 종료해버렸다.

아래는 추상 팩토리 패턴의 예제로 C 스타일의 예제가 없어서 만들어 봤다. class CDBProcess { public: virtual void LoadCharacter() = 0; };class CSDBProcess : public CDBProcess { void LoadCharacter() { printf("SDB\n"); } };class CXDBProcess : public CDBProcess { void LoadCharacter() { printf("XDB\n"); } };class CDBProcessFac { public: virtual CDBProcess* CreateProcess() = 0; };class CXDBProcessFac : public CDBProcessFac { CDBPro..