Design Pattern 썸네일형 리스트형 [Design pattern] Singleton Pattern with C++ 11 Singleton Pattern 1. 정의: 클래스에서 만들 수 있는 인스턴스가 오직 하나일 경우에 이에 대한 접근은 어디에서든지 하나로만 통일하여 제공한다. 2. 기본형 : 기본형의 문제는 Thread Safe 하지 않다는 것이다.: Multi-Thread 환경에서 Race Condition이 발생할 수 있다. 3. Double-Checked Locking Pattern (DCLP): 해제는 제외.: 두 번의 체크와 락을 통해서 Thread 안정성을 확보 한다. 4. Using C++11 Atomic (Acquire and Release Fences)- Atomic Class: 정수형 또는 포인터 타입에 대해 산술 연산들을 atomic하게 수행할 수 있도록 해주는 템플릿 클래스.: 이전 atomic 연.. 더보기 [Design pattern] DECORATOR 패턴 - 장식자(DECORATOR) 의도 - 객체에 동적으로 새로운 책임을 추가할 수 있게 한다. 기능을 추가하려면, 서브 클래스를 생성하는 것보다 융통성 있는 방법을 제공한다. 다른 이름 - 랩퍼(Wrapper) 동기 - 가끔 전체 클래스에 새로운 기능을 추가할 필요는 없지만, 개별적인 객체에 새로운 책임을 추가할 필요가 있다. 예를 들어, GUI툴킷에서 모든 사용자 인터페이스 요소에는 필요 없지만, 어떤 사용자 인터페이스 요소에만 스크롤링(scroling)과 같은 행동이나 테두리(border)와 같은 속성을 추가할 수 있도록 해 줄 필요는 있다. 이런 것은 하나의 객체에 속성이 추가됨으로써 또 다른 책임이 추가되어야 한다. 하지만, 이 같은 방법은 테두리의 선택이 정적이기 때문에, 사용자는 구성요소를.. 더보기 [Design pattern] 반복자 Iterator 패턴 - 반복자(Iterator) 다른 이름 - 커서(Cursor) 키워드 - 반복적인 행동의 일반화 의도 - 내부 표현부를 노출하지 않고 어떤 집합 객체에 속한 원소들을 순차적으로 접근할 수 있는 방밥을 제공한다. 동기 1. 리스트(list)등 집합 객체들은 이 내부 표현 구조를 노출하지 않고도 자신의 원소를 접근할 수 있는 방법을 제공하는 게 좋다. 2. 이미 정의한 방법과 다른 방법으로 이들 원소들을 순회하고자 할 수도 있다. 3. 순회 방법이 바뀌었다고 List 클래스의 인터페이스를 부풀리고 싶지는 않다. 4. 동일한 리스트에 대해서 하나 이상의 순회 방법을 정의하고 싶을 때도 있다. 패턴소개 1. 동기에서 나타난 문제들을 해결할 수 있는 것이, 반복자 패턴이다. 2. 이 패턴은 리스트 객체에 접.. 더보기 [Design pattern] 복합체 Composite 패턴 : 복합체(Composite) 의도 : 부분과 전체의 계층을 표현하기 위해 객체들을 모아 트리 구조로 구성한다. 사용자로 하여금 개별 객체와 복합 객체를 모두 동일하게 다룰 수 있도록 하는 패턴이다. 동기 : 그래픽 편집기나 구조도 캡쳐 시트템 같은 그래픽 응용프로그램을 살펴보면, 사용자가 간단한 그림 구성요들을 모아서 복잡한 다이어그램을 생성할 수 있게 한다. 사용자는 더 큰 그림 요소를 만글기 위해 구성요소들을 그룹으로 만들고, 이 그룹이 다 더큰 그룹을 형성하기도 한다. 이는 마이크로소프트의 파워포인트의 그룹 기능을 생각하면 이해하기 쉽다. 출처 : http://blog.naver.com/gamediz/20042595126 : 1번은 A, B, C, D라는 객체를 놓았다. : 2번은 B객체를 .. 더보기 [Design pattern] 감시자 Observer 패턴 - 감시자(Observer) 패턴 의도 - 객체 사이에 일 대 다수의 의존 관계를 정의해 두어, 어떤 객체의 상태가 변할 때 그 객체에 의존성을 가진 다른 객체들이 그 변화를 통지 받고 자동으로 갱신될 수 있게 만든다. 키워드 - 데이터에 대한 감시자의 자동 갱신 다른 이름 - 종속자(Dependent), 게시-구독(Publish-Subscribe) 동기 1. 어떤 하나의 시스템을 서로 연동되는 클래스 집합으로 분할했을 때 발생하는 공통적인 부작용은 관련된 객체 간에 일관성을 유지하도록 해야 한다는 것이다. 2. 그렇다고 이 일관성 관리를 위해서 객체간의 결합도를 높이고 싶지는 않다. 이유는 각 클래스의 재사용성이 떨어지기 때문이다. 동기 예제. - 그래픽 사용자 인터페이스 툴킷을 예로 든다. 툴킷.. 더보기 [Design pattern] Bridge 패턴: 가교(Bridge)의도: 구현에서 추상을 분리하여, 이들이 독립적으로 다양성을 가질 수 있도록 한다.다른 이름: 핸들/구현부(Handle/Body)동기: 하나의 추상적 개념이 여러가지 구현으로 구체화될 수 있을때, 대부분은 상속을통해서 이 문제를 해결한다. 추상 클래스로 추상적 개념에 대한 인터페이스를 정의하고, 구체적인 서브클래스들에서 서로 다른 방식으로 이들 인터페이스를 구현 한다.그러나, 이런 방법으로는 충분한 융통성을 가질 수 없다. 상속은 구현과 추상적개념을 영구적으로 종속시키기 때문에, 추상적 개념과 구현을 분리해서 재사용하거나수정, 확장하기가 쉽지 않다.활용성:1. 런타임에 구현 방법을 선택하거나 구현 내용을 변경하고 싶을 때.:2. 추상적 개념과 구현 모두가 독립적으로 서브클래싱을 .. 더보기 [Design pattern] Reflection 구현1. 어플리케이션의 모델을 정의2. 변경되는 동작을 정의한다.3. 시스템 구조적 측면들을 정의한다.4. 시스템 서비스를 정의한다.5. metaobjects 를 정의한다.6. MOP 를 정의한다.7. 기본레벨을 정의한다. 장점소스 코드를 임의로 수정할 수 없다.소프트웨어 시스템의 변경이 쉽다.다양한 종류의 변경을 지원한다. 단점메타 레벨에 수정을 가할 경우 손상이 발생할 수 있다.컴포넌트의 개수가 급격히 증가 할 수 있다.효율성이 떨어진다.소프트웨어의 잠재적인 모든 변화를 지원할 수 없다.모든 언어가 리플렉션을 지원하지 않는다. 더보기 [Design pattern] Micro Kernel Micro Kernel 이란? Kernel 의 기능을 최소화하여 각 컴포넌트들 간에 서로 통신할 수 있도록 컴포넌트를 독립된 프로세스에서 실행할 수 있는 기능을 포함 - 프로세스 관리 서비스 - 메모리 관리 서비스 - 파일시스템 서비스 이식(Portable), 확장(extensible), 적응(adaptable) 가능하게 설계 Micro Kernel 구성 요소1) Micro Kernel2) Internal Server - 항상 커널에 있지 않지만 외부에서 바라봤을 때 커널에서 제공해야 하는 핵심 기능, 커널에 의해서만 액세스 되어짐 Ex) 디바이스 드라이버3) External Server - 인터페이스를 외부에 노출 - 마이크로커널이 제공하는 통신 기능을 사용해 클라이언트 애플리케이션 으로부터 서비스 요.. 더보기 [Design pattern] PAC PACPresentation : 시각적인 동작을 위한 컴포넌트Abstraction : 데이터를 핸들링 하는 컴포넌트AgentControl : P, A를 연결하고 다른 Agent들과 통신하기 위한 컴포넌트 구현1.애플리케니션의 모델을 정의한다.2.PAC 계층을 조직화하기 위해 일반 전략을 정의한다.3.최상위 레벨 PAC 에이전트를 정의한다.4.최하위 레벨 PAC 에이전트들을 정의한다.5.시스템 서비스들을 제공하는 최하위 레벨 PAC 에이전트들을 정의한다.6.하위 레벨 PAC 에이전트들을 조합하고 위한 중간 레벨 PAC 에이전트들을 정의한다.7.하위 레벨 PAC 에이전트들을 상호조정하기 위해 중간 레벨 PAC 에이전트들을 정의 한다.8.사람-컴퓨터 상호작용으로부터 핵심 기능을 분리해낸다.9.외부 인터페이스를.. 더보기 [Design pattern] MVC MVC 란 ? 상호 작용 어플리케이션을 구현 할 때 Model, View, Controller 구조로 각각을 분리해서 패턴화 한 것. MVC 구성요소 사용 이유? : 상호 작용 어플리케이션을 구축하다 보면 아래와 같은 문제점 들로 인하여 유연성을 갖춘 시스템 구축이 필요해 짐 문제점? - 고객의 요구에 따라 인터페이스 변경이 잦음 - 릴리즈 되는 어플리케이션 이라면 항상 인터페이스 변경의 도전을 받게 됨 - 사용자에 따른 다른 요구 사항 : 키보드, 마우스 - 같은 데이터가 다른 방법들로 보여지게 됨 - 자동화된 UI 테스트가 어려울 때 동작구현( 1~ 6 기본 구현 ) ( 7 ~ 10 애플리케이션에 유연성을 제공 )1.핵심 기능과 사람- 컴퓨터 상호작용 기능을 분리한다.2.변경전파 메커니즘을 구현한다... 더보기 [Design pattern] Command Processor Command Processor서비스에 대한 요청과 서비스의 실행을 분리한다.요청을 독립적인 객체로 관리하며 실행을 스케줄링 한다.작업취소에 대비해 요청 객체를 저장하는 추가적인 서비스를 제공한다. 문제사용자들마다 나름의 방식으로 애플리케이션을 다루고 싶어한다.애플리케이션의 확장은 기존에 있던 코드에 영향을 미쳐서는 안 된다.작업취소와 같은 추가 서비스는 모든 요청에 대해서 일관적으로 구현되어야 한다. 해법커맨드 프로세서가 모든 커맨드 개체들을 다룬다.커맨드 프로세서는 명령의 실행을 스케줄링하고 추후에 있을지 모를 작업취소에 대비해 명령을 저장한다. 구조동작 구현추상 커맨드 컴포넌트의 인터페이스를 정의한다.각 유형마다 커맨드 컴포넌트를 설계한다.순차적으로 수행되는 몇몇 명령들을 조합한 매크로 명령을 제공.. 더보기 [Design pattern] Proxy Proxy 디자인 패턴은 컴포넌트의 클라이언트로 하여금 컴포넌트 자체가 아니라 컴포넌트의 대리자와 통신하도록 해준다. 이런 위치 보유자는 효율을 향상시키고, 쉽게 엑스스 할 수 있게 해주며 권한을 부여받지 못한 액세스를 방지하는 등의 역활을 할 수 있다. 문제컴포넌트에 액세스하는 작업은 런타임에 효과적이고 비용이 덜 들며 클라이언트와 컴포넌트 모두에 대해 안전해야 한다.컴포넌트에 액세스하는 작업은 클라이언트의 입장에서 투명하고 간단해야 한다. 이 컴포넌트를 호출할 때 사용하는 동작이나 구문이, 직접 액세스할 수 있는 다른 컴포넌트를 호출할 때 사용하는 동작이나 구문과 특별히 다르거나 많이 변경해서는 안 된다. 클라이언트는 원격 클라이언트에 액세스할 경우 일어날 수 있는 성능상 하락이나 비용상 손해에 대해.. 더보기 [Design pattern] Master-Slave Master-Slave - 디자인 패턴은 마스터 컴포터가 자신과 동등한 역활을 하는 Slave에 컴포넌트에 작업을 분산하고, 이 Slave들에서 반환된 결과들로 부터 최종 결과를 계산해내는 패턴이다. 문제.- 클라이언트는 계산이 분할-정복 원칙에 근거하고 있다는 사실을 알 필요가 없다. - 클라이언트나 서브태스크의 처리는 작업을 분할하고 최종 결과를 모으는 알고리즘에 좌우되어서는 안 된다.- 서브태스크들을 처리하기 위해서는 (예를 들어 계산 정확도를 향상시키기 위한 경우처럼) 서로 다르지만 의미적으로 동일한 구현들을 사용하는 것이 좋다. - 서브태스크들을 처리할 때 간혹 조정이 필요하기도 하다. 해법.장애 허용성 – 서비스의 실행을 여러 개의 복제된 구현들에 위임한다. 분할된 서비스의 실행들에 장애가 발.. 더보기 [Design pattern] Whole-Part Whole-Part - 의미적 단위로 컴포넌트를 모으는데 도움을 준다. - Whole 객체(집합 컴포넌트)는 그것을 구성하는 Part(컴포넌트) 객체들을 캡슐화 한다. 문제- 복합 객체는 작은 객체로 분해되거나 기존에 있던 객체들로 구성.- 재사용성, 가변성을 지원하며 객체들을 다른 유형의 집합 객체로 재조합.- 클라이언트는 집합 객체를 자체 구성 부분에 직접 액세스를 허용하지 않는 원자적 개체로 인식. 해법- 더 작은 객체들을 캡슐화하는 컴포넌트를 도입해서, 클라이언트가 컴포넌트의 구성 부분들에 직접 액세스 할 수 없도록 막는다.- 캡슐화된 객체들의 기능에는 직접 액세스할 수 없으며 이 객체들의 기능에 액세스하기 위해서 집합 객체의 인터페이스를 통해야 한다. Whole-Part 패턴의 일반 원칙은 다음.. 더보기 [Design pattern] 팩토리 매서드 패턴 의도 - 객체를 생성하기 위해 인터페이스를 정의하지만, 어떤 클래스의 인스턴스를 생성할지에 대한 결정은 서브 클래스가 내리도록 한다. 활용 - 어떤 클래스가 자신이 생성해야 하는 객체의 클래스를 예측할 수 없을 때 - 생성할 객체를 기술하는 책임을 자신의 서브클래스가 지정했으면 할 때 - 객체 생성의 책임을 몇 개의 보조 서브클래스 가운데 하나에게 위임하고, 어떤 서브클래스가 위임자인지에 대한 정보를 국소화 시키고 싶을 때 더보기 [Design pattern] 빌더 패턴 의도 - 복잡한 객체를 생성하는 방법과 표현하는 방법을 정의하는 클래스를 별도로 분리하여, 서로 다른 표현이라도 이를 생성할 수 있는 동일한 절차를 제공할 수 있어야 한다. 패턴 활용 - 복합 객체의 생성 알고리즘이 이를 합성하는 요소 객체들이 무엇인지 이들의 조립 방법에 독립적일 때 - 합성할 객체들의 표현이 서로 다르더라도 생성 절차에서 이를 지원해야 할 때. 결과 - 제품에 대한 내부 표현을 다양하게 변화할 수 있다. - 생성과 표현에 필요한 코드를 분리한다. - 복합 객체를 생성하는 절차를 좀더 세밀하게 나눌 수 있다. 더보기 [Design Pattern] Thread-Safe Singleton 위의 보이는 것은 일반적으로 사용하는 싱클턴의 방법이다. 하지만 이 방법은 Thread-Safe 하지 않다. 그래서 다음과 같이 바꾸었다. 이런식으로 하면 Thread-Safe 하게 된다고 할 수 있다. 하지만 이 방법 역시 무조건 100%확실하다고 할 순 없다. Debug모드에서는 안전하지만 만일 Release모드일때 컴파일러가스스로 최적화를 해버려 Lock에 동시 접근을 하는 경우가 극히 드물게 나타난다는 전설을... 위의 코드를 테스트는 엄청난 귀찮음이 엄습하는 관계로. 이렇게 Thread 1개 만들고, 100만번 돌려보는 것만으로 종료해버렸다. 더보기 [Design Pattern] The abstract factory pattern example 아래는 추상 팩토리 패턴의 예제로 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.. 더보기 이전 1 다음
