디자인 패턴의 정의
Design Patten/HeadFirstDesignPatten2007. 7. 25. 15:53
패턴이란 특정 컨텍스트 내에서 주어진 문제에 대한 해결책이다.
컨텍스트(context)란 패턴이 적용되는 상황을 뜻한다. 반복적으로 일어날 수 있는 상황이어야만 한다.
ex) 객체들의 컬렉션이 주어져 있다.
문제(problem)란 그 컨텍스트 내에서 이루고자 하는 목적을 뜻한다. 하지만 컨텍스트 내에서 생길 수 있는 제약조건도 문제에 포함된다
ex) 컬렉션의 구현을 드러내지 않으면서 그 안에 있는 각 객체들에 대해서 순환 작업을 할 수 있어야 한다
해결책(solution)이 바로 우리가 찾아내야 하는 것이다. 누구든지 적용해서 일련의 제약조건 내에서 목적을 달성할 수 있는 일반적인 디자인을 뜻한다.
ex) 반복 잡업을 별도의 클래스로 캡슐화시킨다.
어떤 컨텍스트 내에서 일련의 제약조건에 의해 영향을 받을 수 있는 문제에 봉착 했다면, 그 제약 조건 내에서 목적을 달성하기 위한 해결책을 찾아낼 수 있는 디자인을 적용하면 된다.
패턴이 아닌 디자인에 정신을 집중해야 한다. 반드시 필요한 경우에만 패턴을 사용해야 하고 더 간단한 해결책이 있다면 그 방법을 쓰는 것이 옳은 것이다.
Worker Thread 패턴
Design Patten/Java Thread Patten2007. 5. 20. 21:04
일이 올 때까지 기다리고 일이 오면 일한다.
별명 : Thread Pool, Background Thread
문맥 : 쓰레드(Client)가 인스턴스(Host)의 메소드를 호출하고 있다고 합시다.
문제
메소드의 처리에 시간이 걸리면 응답성이 낮아지게 됩니다. 응답성을 높이기 위해서 새로운 쓰레드를 기동해서 메소드를 처리시키면 쓰레드 기동의 시간만큼 스루풋은 저하됩니다. 또 다수의 리퀘스트를 내면 다수의 쓰레드가 기동하게 되어 버려서 용량을 저하시킵니다.
해결법
우선 처리를 실행하는 쓰레드(워커 쓰레드)를 사전에 기동해 둡시다. 그리고 리퀘스트를 표현하는 인스턴스를 워커 쓰레드에 건네는 것입니다. 그렇게 하면 새로운 쓰레드를 매회 기동할 필요가 없게 됩니다.
관련
워커 쓰레드의 처리 결과를 호출하는 측에 건내줄 때에는 Future 패턴을 사용합니다.
리퀘스트를 표현하는 인스턴스를 워커 쓰레드에 건내줄 떼에는 Producer-Consumer 패턴을 사용합니다.
별명 : Thread Pool, Background Thread
문맥 : 쓰레드(Client)가 인스턴스(Host)의 메소드를 호출하고 있다고 합시다.
문제
메소드의 처리에 시간이 걸리면 응답성이 낮아지게 됩니다. 응답성을 높이기 위해서 새로운 쓰레드를 기동해서 메소드를 처리시키면 쓰레드 기동의 시간만큼 스루풋은 저하됩니다. 또 다수의 리퀘스트를 내면 다수의 쓰레드가 기동하게 되어 버려서 용량을 저하시킵니다.
해결법
우선 처리를 실행하는 쓰레드(워커 쓰레드)를 사전에 기동해 둡시다. 그리고 리퀘스트를 표현하는 인스턴스를 워커 쓰레드에 건네는 것입니다. 그렇게 하면 새로운 쓰레드를 매회 기동할 필요가 없게 됩니다.
관련
워커 쓰레드의 처리 결과를 호출하는 측에 건내줄 때에는 Future 패턴을 사용합니다.
리퀘스트를 표현하는 인스턴스를 워커 쓰레드에 건내줄 떼에는 Producer-Consumer 패턴을 사용합니다.
- 자바로 배우는 디자인 패턴 입문 -
Single Threaded Execution 패턴(Immutable 패턴)
Design Patten/Java Thread Patten2007. 5. 16. 20:00
없애려고 해도 없어지지 않아
문맥 : 복수의 쓰레드가 인스턴스를 공유하고 있지만 인스턴스의 상태가 변화하는 것은 아닙니다.
문제 : Single Threaded Execution 패턴을 사용하면 스루풋이 떨어져버립니다.
해결법
인스턴스가 만들어진 후 상태가 변화하는 것이 아니라면 Single Threaded Execution 패턴을 사용하는 것은 그만둡시다. 실수로 상태가 변화하는 코드를 쓰지 않도록 하기 위해 쓰레드가 필드를 변경하지 못하도록 합니다. 또 인스턴스의 상태를 변경하는 메소드(setter)가 있으면 소거합니다. 인스턴스의 상태를 알아보는 메소드(getter)는 있어도 상관없습니다.
이것이 Immutable 패턴입니다. Immutable 패턴을 사용하면 스루풋은 향상됩니다. 그러나 불변성(immutability)을 계속 보유하는 것은 곤란합니다. 문서에 그 클래스가 immutable인 것을 확실히 알아둡시다.
구현
자바에서는 필드를 은폐하기 위해 private를 사용합니다. 또한 변경할 수 없도록 하기 위해 final을 사용합니다.
관련
복수의 쓰레드를 배타 제어할 때에는 Single Threaded Execution 패턴을 사용합니다.
변경하는 쓰레드가 참조하는 쓰레드의 수보다 적을 때에는 Read-Write Lock 패턴을 사용 합니다.
문맥 : 복수의 쓰레드가 인스턴스를 공유하고 있지만 인스턴스의 상태가 변화하는 것은 아닙니다.
문제 : Single Threaded Execution 패턴을 사용하면 스루풋이 떨어져버립니다.
해결법
인스턴스가 만들어진 후 상태가 변화하는 것이 아니라면 Single Threaded Execution 패턴을 사용하는 것은 그만둡시다. 실수로 상태가 변화하는 코드를 쓰지 않도록 하기 위해 쓰레드가 필드를 변경하지 못하도록 합니다. 또 인스턴스의 상태를 변경하는 메소드(setter)가 있으면 소거합니다. 인스턴스의 상태를 알아보는 메소드(getter)는 있어도 상관없습니다.
이것이 Immutable 패턴입니다. Immutable 패턴을 사용하면 스루풋은 향상됩니다. 그러나 불변성(immutability)을 계속 보유하는 것은 곤란합니다. 문서에 그 클래스가 immutable인 것을 확실히 알아둡시다.
구현
자바에서는 필드를 은폐하기 위해 private를 사용합니다. 또한 변경할 수 없도록 하기 위해 final을 사용합니다.
관련
복수의 쓰레드를 배타 제어할 때에는 Single Threaded Execution 패턴을 사용합니다.
변경하는 쓰레드가 참조하는 쓰레드의 수보다 적을 때에는 Read-Write Lock 패턴을 사용 합니다.
- Java언어로 배우는 디자인 패턴 입문 -
Read-Write Lock 패턴
Design Patten/Java Thread Patten2007. 5. 16. 19:39
모두 읽어도 좋지만 일고 있을 때에는 쓰면 안돼요.
별명 : Reader Writer, Reader/Writer Lock, Readers/Writer Lock
문맥 : 복수의 쓰레드가 인스턴스를 공유하고 있어 인스턴스의 상태를 참조하는 것뿐인 쓰레드(Reader)와 변경하는 쓰레드(Writer)가 존재하고 있다고 합시다.
문제 : 쓰레드 간에 배타 제어를 하지 않으면 안정성을 잃게 됩니다. 그러나 Single Threaded Execution 패턴을 사용하면 스루풋이 떨어져 버립니다.
해결법 : 우선 『Reader를 제어하는 락』과 『Writer를 제어하는 락』을 나누어 이 두종류의락을 제공하는 ReadWriteLock을 도입해 봅시다. ReadWriteLock은『Writer 끼리 』및 『Reader와 Writer』의 배타 제어를 합니다. 『Reader 끼리』는 충돌해도 안정성에 영향을 주지 않기 때문에 배타 제어는 하지 않습니다. 이것으로 안정성을 잃어 버리지 않고 스루픗을 향상 시킬 수 있습니다. 이것이 Read-Write Lock 패턴이니다.
구현 : 자바에서는 finally를 사용하면 락의 해제를 잊어버리는 것을 방지할 수 있습니다.
관련 : Read-Write Lock 패턴의 ReadWriteLock이 배타 제어를 실현하는 부분에서는 Guarded Suspension 패턴을 사용합니다.
Writer가 전혀 존재하지 않을 때에는 Immutable 패턴을 사용합니다.
별명 : Reader Writer, Reader/Writer Lock, Readers/Writer Lock
문맥 : 복수의 쓰레드가 인스턴스를 공유하고 있어 인스턴스의 상태를 참조하는 것뿐인 쓰레드(Reader)와 변경하는 쓰레드(Writer)가 존재하고 있다고 합시다.
문제 : 쓰레드 간에 배타 제어를 하지 않으면 안정성을 잃게 됩니다. 그러나 Single Threaded Execution 패턴을 사용하면 스루풋이 떨어져 버립니다.
해결법 : 우선 『Reader를 제어하는 락』과 『Writer를 제어하는 락』을 나누어 이 두종류의락을 제공하는 ReadWriteLock을 도입해 봅시다. ReadWriteLock은『Writer 끼리 』및 『Reader와 Writer』의 배타 제어를 합니다. 『Reader 끼리』는 충돌해도 안정성에 영향을 주지 않기 때문에 배타 제어는 하지 않습니다. 이것으로 안정성을 잃어 버리지 않고 스루픗을 향상 시킬 수 있습니다. 이것이 Read-Write Lock 패턴이니다.
구현 : 자바에서는 finally를 사용하면 락의 해제를 잊어버리는 것을 방지할 수 있습니다.
관련 : Read-Write Lock 패턴의 ReadWriteLock이 배타 제어를 실현하는 부분에서는 Guarded Suspension 패턴을 사용합니다.
Writer가 전혀 존재하지 않을 때에는 Immutable 패턴을 사용합니다.
- Java언어로 배우는 디자인 패턴 입문 -
Producer-Consumer 패턴
Design Patten/Java Thread Patten2007. 5. 16. 15:02
내가 만들고 당신이 쓰는
문맥 : 어떤 쓰레드(Producer)에서 다른 쓰레드(Consumer)에 데이터를 넘겨준다고 합시다.
문제 : Producer 와 Consumer의 처리 속도가 다르면 늦은 쪽이 빠른쪽의 다리를 잡아끌어서 스루풋이 떨어진다. 또 Producer가 데이터를 쓸 때 동시에 Consumer가 데이터를 읽으려고 하면 안정성이 떨어진다.
해결법
Producer와 Consumer의 사이에 중간 지점이 되는 Channel을 준비합시다. 그리고 Channel에 복수의 데이터를 보유시킵니다. 그렇게 하면 Producer와 Consumer의 처리 속도 차를 완화할 수 있습니다. 또 Channel중에서 쓰레드의 배타 제어를 하면 데이터의 안정성도 잃어버리지 않습니다. 이것으로 스루풋을 떨어뜨리지 않고 더군다나 복수 쓰레드 간에 안전하게 데이터를 주고받을 수 있습니다.
이것이 Producer-Consumer 패턴입니다.
관련
Channel이 데이터를 안전하게 주고받는 부분에서는 Guarded Suspension 패턴을 사용합니다.
Future 패턴에서 반환값을 건넬 때에는 Producer-Consumer 패턴을 사용합니다.
Worker Thread 패턴으로 요구를 건넬 때에는 Producer-Consumer 패턴을 사용합니다.
ps. 쓰레드간에 직접 주고받는 통신을 하지 않고, 중간에 연결 고리를 두어서 그곳을 통해 거래를 하는 방식..
문맥 : 어떤 쓰레드(Producer)에서 다른 쓰레드(Consumer)에 데이터를 넘겨준다고 합시다.
문제 : Producer 와 Consumer의 처리 속도가 다르면 늦은 쪽이 빠른쪽의 다리를 잡아끌어서 스루풋이 떨어진다. 또 Producer가 데이터를 쓸 때 동시에 Consumer가 데이터를 읽으려고 하면 안정성이 떨어진다.
해결법
Producer와 Consumer의 사이에 중간 지점이 되는 Channel을 준비합시다. 그리고 Channel에 복수의 데이터를 보유시킵니다. 그렇게 하면 Producer와 Consumer의 처리 속도 차를 완화할 수 있습니다. 또 Channel중에서 쓰레드의 배타 제어를 하면 데이터의 안정성도 잃어버리지 않습니다. 이것으로 스루풋을 떨어뜨리지 않고 더군다나 복수 쓰레드 간에 안전하게 데이터를 주고받을 수 있습니다.
이것이 Producer-Consumer 패턴입니다.
관련
Channel이 데이터를 안전하게 주고받는 부분에서는 Guarded Suspension 패턴을 사용합니다.
Future 패턴에서 반환값을 건넬 때에는 Producer-Consumer 패턴을 사용합니다.
Worker Thread 패턴으로 요구를 건넬 때에는 Producer-Consumer 패턴을 사용합니다.
ps. 쓰레드간에 직접 주고받는 통신을 하지 않고, 중간에 연결 고리를 두어서 그곳을 통해 거래를 하는 방식..
- Java언어로 배우는 디자인 패턴 입문 -
Balking 패턴.
Design Patten/Java Thread Patten2007. 5. 15. 14:47
필요 없으면 관둬요.
문맥 : 복수의 쓰레드가 인스턴스를 공유하고 있다고 할때.
문제 : 복수의 쓰레드가 마음대로 인스턴스에 액세스하면 인스턴스의 안정성을 잃어버리게 된다.
그러나 안전한 타이밍을 기다리고 있으면 응답성이 저하된다.
해결법
인스턴스의 상태가 부적절한 때에는 처리를 중단합시다. 우선 인스턴스의 '적절한 상태'를 '가드 조건' 으로 표현한다. 그리고 안정성을 잃어버릴 위험이 있는 처리를 하기 전에 가드 조건이 충족되었는지 테스트 한다. 가드 조건이 충족되어 있을때에만 실행을 계속 한다.가드 조건이 충족되어 있지 않으면 실핼을 중단(balk)하고 곧장 돌아간다.
구현
자바에서는 가드 조건의 테스트에 if 문을 사용한다. balk하는 데에는 return으로 메소드에서 돌아오거나 throw로 예외를 던진다. 가드 조건의 테스트와 변경은 Single Threaded Execution 패턴을 사용한다.
관련
가드 조건이 충족되기까지 기다리고 싶을 때에는 Guarded Suspension을 사용합니다.
Balking 패턴의 가드 조건의 테스트와 변경을 기술하는 부분에서는 Single Threaded Execution 패턴을 사용합니다.
문맥 : 복수의 쓰레드가 인스턴스를 공유하고 있다고 할때.
문제 : 복수의 쓰레드가 마음대로 인스턴스에 액세스하면 인스턴스의 안정성을 잃어버리게 된다.
그러나 안전한 타이밍을 기다리고 있으면 응답성이 저하된다.
해결법
인스턴스의 상태가 부적절한 때에는 처리를 중단합시다. 우선 인스턴스의 '적절한 상태'를 '가드 조건' 으로 표현한다. 그리고 안정성을 잃어버릴 위험이 있는 처리를 하기 전에 가드 조건이 충족되었는지 테스트 한다. 가드 조건이 충족되어 있을때에만 실행을 계속 한다.가드 조건이 충족되어 있지 않으면 실핼을 중단(balk)하고 곧장 돌아간다.
구현
자바에서는 가드 조건의 테스트에 if 문을 사용한다. balk하는 데에는 return으로 메소드에서 돌아오거나 throw로 예외를 던진다. 가드 조건의 테스트와 변경은 Single Threaded Execution 패턴을 사용한다.
관련
가드 조건이 충족되기까지 기다리고 싶을 때에는 Guarded Suspension을 사용합니다.
Balking 패턴의 가드 조건의 테스트와 변경을 기술하는 부분에서는 Single Threaded Execution 패턴을 사용합니다.
- Java언어로 배우는 디자인 패턴 입문 -
