검색결과 리스트
분류 전체보기에 해당되는 글 253건
- 2011.12.05 [Design] Composite Pattern
- 2011.12.05 [Design] Iterator Pattern
- 2011.12.02 [Design] Template Method
- 2011.11.29 [Design] Facade Pattern
- 2011.11.29 [Design] Adapter Pattern
- 2011.11.29 [Design] Command Pattern
- 2011.11.29 [Design] Singtone Pattern
- 2011.11.29 [Design] Decorator Pattern
- 2011.11.25 [Design]Observer Pattern
- 2011.11.24 [Design]Factory Method Pattern
글
컴포지트 패턴..
객체들을 각기 트리 구조로 구성하여 복합 객체를 서로 다른 객체들을 같은 방법으로 접근 가능하게 한다.
단순한 트리 구조에 상위 노드에 정보를 모두 모아두고 그 내용들을 이터레이터를 이용하여 뽑아내어 쓴다.
B-TREE 를 생각하면 안되고 하나의 부모에 여러 LEAP가 달린 구조를 생각하면 이해가 쉬울 것이다.
객체들을 각기 트리 구조로 구성하여 복합 객체를 서로 다른 객체들을 같은 방법으로 접근 가능하게 한다.
단순한 트리 구조에 상위 노드에 정보를 모두 모아두고 그 내용들을 이터레이터를 이용하여 뽑아내어 쓴다.
B-TREE 를 생각하면 안되고 하나의 부모에 여러 LEAP가 달린 구조를 생각하면 이해가 쉬울 것이다.
설정
트랙백
댓글
글
이터레이터 패턴.. 말 그대로 반복자이다.
개별적으로 반복자를 만들어서 그 내용을 외부로 노출시키지 않고 각 항목에 접근이 가능하다.
일단 코드로 구현은 해 봤지만 상황에 따라 다르고 한다고 해도 C#에서 제공해주는
IEnumerator를 이용하는게 좀 더 편하다고 느껴진다.
뭐.. 상황에 따라서 다르겠지만 지금 당장은 그렇다는 생각이 강하게 든다.
개별적으로 반복자를 만들어서 그 내용을 외부로 노출시키지 않고 각 항목에 접근이 가능하다.
일단 코드로 구현은 해 봤지만 상황에 따라 다르고 한다고 해도 C#에서 제공해주는
IEnumerator를 이용하는게 좀 더 편하다고 느껴진다.
뭐.. 상황에 따라서 다르겠지만 지금 당장은 그렇다는 생각이 강하게 든다.
설정
트랙백
댓글
글
기본적인 알고리즘 골격을 잡는 것에 좋다.
일부는 추상 클래스 내에서 구현을 하고, 일부는 상속받는 클래스 내에서 구현을 할 수가 있다.
기본적인 추상 클래스를 이용하여 짤 경우 많이 볼 수가 있다.
얼추보면 팩토리 패턴과 비슷한 느낌이기는 하나, 최상위 클래스 내에 그 행동들을 실행하는 템플릿 메소드가 존재한다.
뭐.. 단지 이런 차이가 아닐까 라는 생각도 든다.
팩토리 메소드 경우는 중간에 클래스를 두고 각기 해당하는 내용들에 대해서 처리 할 수 있지만
템플릿 메소드의 경우 각 해당하는 부분 부분을 나눠서 구현이 가능하고, 그 실행 주체를 최상위 클래스에 둔다는 점에서 다른 듯 하다.
일부는 추상 클래스 내에서 구현을 하고, 일부는 상속받는 클래스 내에서 구현을 할 수가 있다.
기본적인 추상 클래스를 이용하여 짤 경우 많이 볼 수가 있다.
얼추보면 팩토리 패턴과 비슷한 느낌이기는 하나, 최상위 클래스 내에 그 행동들을 실행하는 템플릿 메소드가 존재한다.
뭐.. 단지 이런 차이가 아닐까 라는 생각도 든다.
팩토리 메소드 경우는 중간에 클래스를 두고 각기 해당하는 내용들에 대해서 처리 할 수 있지만
템플릿 메소드의 경우 각 해당하는 부분 부분을 나눠서 구현이 가능하고, 그 실행 주체를 최상위 클래스에 둔다는 점에서 다른 듯 하다.
설정
트랙백
댓글
글
퍼사드 패턴..
뭐랄까..
그냥 나누어진 기능 덩어리를 한 클래스에 다 넣어놓고
각기 해당하는 기능의 메소드를 따로 정의 하여 그놈을 호출하면 된다.. 라는 느낌이 강하게 든다.
리모컨을 생각해보면 리모컨 안에는 많은 기능들이 있다.
그 기능을 감싸고 있는건 리모컨 박스..
그 안에서 각기 해당하는 놈들을 작동 시킨다고 생각하면 이해가 더 빠를거 같다.
즉 어떤 하위 시스템의 기능을 통합한 인터페이스를 제공하느 방식이다.
퍼사드는 이게 전부이다.
여기에서 보면 Mp3와 Movie가 하위 시스템이다
Facade 내부에는 이 모든 것을 포함하고 있고
클라이언트에서는 Facade 내부의 해당하는 메소드를 이용하여 각기 그 기능을 실행한다.
뭐랄까..
그냥 나누어진 기능 덩어리를 한 클래스에 다 넣어놓고
각기 해당하는 기능의 메소드를 따로 정의 하여 그놈을 호출하면 된다.. 라는 느낌이 강하게 든다.
리모컨을 생각해보면 리모컨 안에는 많은 기능들이 있다.
그 기능을 감싸고 있는건 리모컨 박스..
그 안에서 각기 해당하는 놈들을 작동 시킨다고 생각하면 이해가 더 빠를거 같다.
즉 어떤 하위 시스템의 기능을 통합한 인터페이스를 제공하느 방식이다.
퍼사드는 이게 전부이다.
여기에서 보면 Mp3와 Movie가 하위 시스템이다
Facade 내부에는 이 모든 것을 포함하고 있고
클라이언트에서는 Facade 내부의 해당하는 메소드를 이용하여 각기 그 기능을 실행한다.
설정
트랙백
댓글
글
어댑터 패턴.
어릴적.. 110V 콘덴서가 기억이 난다.
220V 바뀌고 난 다음 어쩔 수 없이 110V 연결 위에서 콘덴서를 이용 했던 적이!!
그 콘덴서가 바로 Adapter 역할을 하는 것이다.
하나의 인터페이스를 타겟으로 할 경우에는 Adapter Pattern을 이용하면 좋다.
여러 상황을 보면 다중 어댑터를 구현 해야 할 경우도 있다.
Turkey를 어댑터를 이용하여 Duck 로 변환하고자 할 경우
Duck duck = new U_adapter() 방식으로 변환하여 쓴다.
물론 U_adapter에는 그에 맞게 행동하는 내용들이 변환된 호출한 내용을 포함을 한다.
어릴적.. 110V 콘덴서가 기억이 난다.
220V 바뀌고 난 다음 어쩔 수 없이 110V 연결 위에서 콘덴서를 이용 했던 적이!!
그 콘덴서가 바로 Adapter 역할을 하는 것이다.
하나의 인터페이스를 타겟으로 할 경우에는 Adapter Pattern을 이용하면 좋다.
여러 상황을 보면 다중 어댑터를 구현 해야 할 경우도 있다.
Turkey를 어댑터를 이용하여 Duck 로 변환하고자 할 경우
Duck duck = new U_adapter() 방식으로 변환하여 쓴다.
물론 U_adapter에는 그에 맞게 행동하는 내용들이 변환된 호출한 내용을 포함을 한다.
설정
트랙백
댓글
글
커맨드 패턴은 각각의 요구 사항을 캡슐화 하여 그 내용을 실행 시키게 한다.
예를 들어 불을 켜거나 끌 때에 각기 해당 내용이 실행되는 것을 생각해보면 될 것이다.
전문적인 용어 상황에서 본다면
클라이언트의 요구에 의해 인보커는 그 요청에 대한 내용을 실행하도록 리시버에 요청을 하면 리시버는 그 내용을 실행한다.
커맨드 패턴은 주로 스케쥴러, 스레드 풀, 큐 같은 용도에서 쓸 수가 있고
순차적으로 이루어진 작업임으로 이 전 데이터로 돌리기도 쉬운편이다.
Main에서 먼저 Remote(인보커)를 생성하고, 그 후 리시버(Command)에 특정 행동들을 요구한다(Lignt, Door).
VS2008에서의 다이어그램 구성은 저기 까지 나옴으로 샘플을 참조하는 것이 좋을 것 같다.
예를 들어 불을 켜거나 끌 때에 각기 해당 내용이 실행되는 것을 생각해보면 될 것이다.
전문적인 용어 상황에서 본다면
클라이언트의 요구에 의해 인보커는 그 요청에 대한 내용을 실행하도록 리시버에 요청을 하면 리시버는 그 내용을 실행한다.
커맨드 패턴은 주로 스케쥴러, 스레드 풀, 큐 같은 용도에서 쓸 수가 있고
순차적으로 이루어진 작업임으로 이 전 데이터로 돌리기도 쉬운편이다.
Main에서 먼저 Remote(인보커)를 생성하고, 그 후 리시버(Command)에 특정 행동들을 요구한다(Lignt, Door).
VS2008에서의 다이어그램 구성은 저기 까지 나옴으로 샘플을 참조하는 것이 좋을 것 같다.
설정
트랙백
댓글
글
싱글톤 패턴..
유일하게 하나의 정의만 있어야 하는 패턴이다.
일반적으로 우리가 쓰는 싱글톤은 다음과 같이 쓸 것이다.
Object m_obj;
Object _obj
{
get
{
if(m_obj==null)
m_obj = new Object
return m_obj;
{
}
하지만 여기에서 문제가 있다.
멀티스레드에 의해서 생기는 문제로 동기화가 되지 않아 여러번 생성이 된다는 경우가 종종 생긴다.
그럴 경우에는 분명 데이터가 뒤죽 박죽으로 흘러 갈 것이다.
그 다음으로 쓰는 방법이 아마 일반적으로 static 을 이용 할 것이다.
static Object m_obj;
static Object _obj
{
get
{
if(m_obj==null)
m_obj = new Object
return m_obj;
{
}
이는 어느 정도 문제를 해결해 주지만 한번도 쓰이지 않을 경우 메모리만 선점하고 있다는 문제가 생긴다.
필자도 저 방식으로 종종 쓰는 경우가 많다(쓰레드 환경 제외)
멀티쓰레드라면 아마 이 방법이 제일 좋을 것 같다. lock 키워드를 이용하는 것이다.
(lock은 monitor와 같이 동기화를 이용 할 때 쓰는 키워드이다.)
static Object m_obj;
static Object _obj
{
get
{
if(m_obj==null)
lock(m_obj)
{
m_obj = new Object
}
return m_obj;
{
}
이 방법은 인스턴트 생성시 걸리는 시간 때문이다. 이렇게 lock을 걸어 둔다면 멀티쓰레드 환경 상에서는 최소한의 속도가 유지 될 것이다.
유일하게 하나의 정의만 있어야 하는 패턴이다.
일반적으로 우리가 쓰는 싱글톤은 다음과 같이 쓸 것이다.
Object m_obj;
Object _obj
{
get
{
if(m_obj==null)
m_obj = new Object
return m_obj;
{
}
하지만 여기에서 문제가 있다.
멀티스레드에 의해서 생기는 문제로 동기화가 되지 않아 여러번 생성이 된다는 경우가 종종 생긴다.
그럴 경우에는 분명 데이터가 뒤죽 박죽으로 흘러 갈 것이다.
그 다음으로 쓰는 방법이 아마 일반적으로 static 을 이용 할 것이다.
static Object m_obj;
static Object _obj
{
get
{
if(m_obj==null)
m_obj = new Object
return m_obj;
{
}
이는 어느 정도 문제를 해결해 주지만 한번도 쓰이지 않을 경우 메모리만 선점하고 있다는 문제가 생긴다.
필자도 저 방식으로 종종 쓰는 경우가 많다(쓰레드 환경 제외)
멀티쓰레드라면 아마 이 방법이 제일 좋을 것 같다. lock 키워드를 이용하는 것이다.
(lock은 monitor와 같이 동기화를 이용 할 때 쓰는 키워드이다.)
static Object m_obj;
static Object _obj
{
get
{
if(m_obj==null)
lock(m_obj)
{
m_obj = new Object
}
return m_obj;
{
}
이 방법은 인스턴트 생성시 걸리는 시간 때문이다. 이렇게 lock을 걸어 둔다면 멀티쓰레드 환경 상에서는 최소한의 속도가 유지 될 것이다.
설정
트랙백
댓글
글
데코레이터 패턴.
메인 객체에 각기 더 올리고자 하는 객체들을 덧 씌워서 그 결과를 나타낸다.
쉽게 생각하면 커피를 떠올리면 된다.
에스프레소에 우유를 넣고 모카를 넣고 원하는 취향대로 하면 하나의 제품이 나온다.
특징이라고 하면 한 객체를 여러 데코레이터들로 감쌀 수 있다는 것과
자신이 장식한 객체에 어떤 행동을 위임 또는 추가적인 작업을 할 수 있다.
즉 언제든 객체를 감쌀 수가 있기에 프로그램 실행 중 유동적으로 데코레이터를 이용 할 수 있다.
아래는 다이어그램과 샘플 코드 이다.
메인 객체에 각기 더 올리고자 하는 객체들을 덧 씌워서 그 결과를 나타낸다.
쉽게 생각하면 커피를 떠올리면 된다.
에스프레소에 우유를 넣고 모카를 넣고 원하는 취향대로 하면 하나의 제품이 나온다.
특징이라고 하면 한 객체를 여러 데코레이터들로 감쌀 수 있다는 것과
자신이 장식한 객체에 어떤 행동을 위임 또는 추가적인 작업을 할 수 있다.
즉 언제든 객체를 감쌀 수가 있기에 프로그램 실행 중 유동적으로 데코레이터를 이용 할 수 있다.
아래는 다이어그램과 샘플 코드 이다.
설정
트랙백
댓글
글
옵져버 패턴...
말 그대로 감시자다.
그 감시자가 각각의 객체들을 관리하고 매 상황 변화에 따른 정보를 넘겨 줄 수 있다.
즉 하나의 주제에 대하여 1:N 관계를 나타내는 로직에 유용하게 쓸 수가 있다.
헤드 퍼스트 책을 참조한 코드는 이렇다.
날씨에 대한 주체적인 클래스를 중심으로 하여 각각의 상황에 맞는 옵져버를 생성하고 인터페이스 형태로 리스트를 관리하는 방식이다.
말 그대로 감시자다.
그 감시자가 각각의 객체들을 관리하고 매 상황 변화에 따른 정보를 넘겨 줄 수 있다.
즉 하나의 주제에 대하여 1:N 관계를 나타내는 로직에 유용하게 쓸 수가 있다.
헤드 퍼스트 책을 참조한 코드는 이렇다.
날씨에 대한 주체적인 클래스를 중심으로 하여 각각의 상황에 맞는 옵져버를 생성하고 인터페이스 형태로 리스트를 관리하는 방식이다.
설정
트랙백
댓글
글
팩토리 메소드 패턴.
각기 상황에 적합하게 객체를 대신 생성하는 메소드를 통하여 구현된 팩토리 패턴의 확장형이다.
일반적으로 팩토리 패턴의 경우 상속받은 내용에 대하여 각기 new 키워드를 통하여 객체를 생성하는데
만약 프로그램 구조가 확대대고 할 경우 중개자를 통하여 해당하는 객체를 생성하고
거기에 적합한 작업을 하는데에는 이 구조가 더 적합하다.
샘플 코드는 역시나!! 곰을 주제로 해서 간단히 작성 해 봤다 -_-a
디자인 패턴에 대해 아는 것이 많은 분들이 훈수를 둬 줬으면 좋겠다 ㅠ-ㅠ
각기 상황에 적합하게 객체를 대신 생성하는 메소드를 통하여 구현된 팩토리 패턴의 확장형이다.
일반적으로 팩토리 패턴의 경우 상속받은 내용에 대하여 각기 new 키워드를 통하여 객체를 생성하는데
만약 프로그램 구조가 확대대고 할 경우 중개자를 통하여 해당하는 객체를 생성하고
거기에 적합한 작업을 하는데에는 이 구조가 더 적합하다.
샘플 코드는 역시나!! 곰을 주제로 해서 간단히 작성 해 봤다 -_-a
디자인 패턴에 대해 아는 것이 많은 분들이 훈수를 둬 줬으면 좋겠다 ㅠ-ㅠ
RECENT COMMENT