본문 바로가기

반응형

pattern

(4)
Flyweight Pattern 의도 작은 크기의 객체들의 수가 폭발적으로 늘어나는 것을 방지하기 위해 공유 개념을 도입. 동기 객체 지향적으로 설계함으로써 많은 유연성과 재활용성을 기대 할 수 있기는 하지만 늘어만 가는 클래스들을 보고 있노라면 그 비용이 만만치 않음을 느낀다. 클래스를 작은 단위 요소까지 나누어서 설계를 한다면 어플리케이션의 응용성을 높일 수 있고, 해당 요소들을 일관성 있게 다룰 수도 있으며, 요소들에 새로운 기능을 추가하거나 수정한다고 해도 다른 기능에 아무런 영향을 주지 않을 수 있다. 하지만 너무 작은 요소들까지 객체로 다룰때 폭발적으로 늘어나는 객체를 처리 하는 비용은 만만치가 않다. Flyweight 패턴은 이러한 문제를 '공유'를 통해 해결하고자 하는 것이다. 구조참여 객체 * Flyweight - ex..
Composite Pattern 의도 '전체 – 부분'을 표현하기 위해 객체들을 트리구조로 묶을 수 있다. 클라이언트 코드는 각 개별적인 객체(부분)와 다른 객체를 포함하는 객체(전체)를 동일한 인터페이스를 통해 사용할 수 있다. 구조 위의 모델에서 Composite 클래스는 Component 인터페이스를 포함하는 형식으로, 실제적으로 Component 인터페이스에는 Leaf나 Composite의 인스턴스를 가리키게 된다. 이런 구조를 인스턴스 다이어그램으로 표현 하면 아래와 같다. 하나의 집합객체(Composite)가 Leaf나 Composite를 포함하고 그것은 재귀적으로 계속 이어진다. 모든 인스턴스들은 Component 인터페이스를 구현하고 있기 때문에 클라이언트에서는 Leaf와 Composite에 구분없이 동일하게 취급이 가능..
Leader/Follower pattern 얼마전에 libevent가 threadsafe 하지 않다는 글을 대충 번역 해서 올렸더니, 지인이 leader/follower pattern이라는 것을 소개 해줬다. 인터넷 검색 결과 ACE framework에서 사용 되는 서버패턴의 일종이라는데 아직 구현을 해보지 않아서 성능이 얼마나 나올는지는 장담하지 못한다. 내가 구현 하려고 했던 형식은 이벤트(accept/read ..etc)를 감시하는 thread가 하나 있고, 이벤트가 발생하면 event queue에 그 이벤트들을 집어 넣는다. 그럼 event queue 반대편의 worker thread들이 그 이벤트에 맞는 핸들링을 하는 구조 였는데 오버헤드가 많아서 실질적으로 사용하기는 다소 무리가 있는 형식이었다. 그에 반에 leader/follower..
Singleton in Multi Thread 들어가며 이번 포스트는 멀티 스레드 환경에서 싱글톤을 사용할 때 흔히 할 수 있는 실수 한가지에 대해서 살펴 보고자한다. 설명을 위해 한가지 상황을 만들어보자. 우리는 지금 부터 싱글톤 이벤트 큐를 만들어야 한다고 가정. 각종 read/write 작업들을 '싱글톤' 이벤트 큐에 집어 넣고, 몇 개의 '스레드'들이 큐를 감시하다, 큐에 새로운 이벤트가 들어 오면 이벤트에 따라 적적한 작업을 해주는 방식인 전형적인 producer/consumer 방식이다. 이 상황에서 중요한것은 '싱글톤'과 몇개의 '스레드'들이다. 그리고 스레드를 만들게 되면 의례 그렇듯이 아래와 같이 레이스 컨디션이 발생하게 된다. 시간 ThreadA ThreadB 1 if(queue.empty()) -> not empty 2 if(qu..

반응형