[DP] 15. Structural Patterns 정리 - 15 분
[구성]
[Session 1] Part1. Orientation 1
[Session 1] Part2. Orientation 2
[Session 1] Part3. Abstract Factory 패턴
[Session 1] Part4. Builder 패턴
[Session 1] Part5. Factory Method 패턴
[Session 1] Part6. Prototype 패턴
[Session 1] Part7. Singleton 패턴
[Session 2] Part1. Adapter 패턴
[Session 2] Part2. Bridge 패턴
[Session 2] Part3. Composite 패턴
[Session 2] Part4. Decorator 패턴
[Session 2] Part5. Facade 패턴
[Session 2] Part6. Flyweight 패턴
[Session 2] Part7. Proxy 패턴
[Session 3] Part1. Chain of Responsibility 패턴
[Session 3] Part2. Command 패턴과 Template Functor
[Session 3] Part3. Interpreter 패턴
[Session 3] Part4. Iterator 패턴
[Session 3] Part5. Mediator 패턴
[Session 3] Part6. Memento 패턴
[Session 4] Part1. Observer 패턴
[Session 4] Part2. State 패턴
[Session 4] Part3. Strategy 패턴
[Session 4] Part4. Template Method 패턴
[Session 4] Part5. Visitor 패턴
[Session 4] Part6. 디자인 패턴 요약 및 적용 방안
Behavioral Patterns 목적 및 유용성
객체들간의 알고리즘이나 역할 분담 방식을 다루는 것
즉, Behavioral Pattern 들은 객체나 클래스의 구조에 대해 다루는 것이 아니라, 그들간의 교류 방식에 대해 다루는 것이다.
실행시간에 추적하기 어려운 복잡한 제어 흐름이 드러나도록 해준다.
따라서 Behavioral Pattern은 우리가 더 이상 복잡한 제어 흐름에 신경쓰지 않고, 객체들간의 교류 방식에 집중할 수 있도록 해줄것이다.
Class Behavioral Patterns vs Object Behavioral Patterns
Class Behavioral 패턴
-클래스간 상속 관계를 이용해 행위 분산이 이루어지도록 하는 것
-대표적으로 Template method 패턴과 Interpreter 패턴이 있다.
Object Behavioral 패턴
-상속 관계보다는 객체들간에 구성 관계를 이용하여 행위를 분산 처리하는 방식
-이때 관건은 한 객체가 어떻게 다른 객체 대해서 아는가 하는 점인데, 만약 모든 객체들이 서로 서로를 알아야 한다면 객체들간의 결합도(coupling)가 증가하여 바람직하지 않을 것이다.
-따라서, Object Behavioral 패턴들은 여러 객체들에게 행위를 분산시키되 객체들간의 결합도를 낮출 수 있는 방식들을 제시할 것이다.
[문제 사례 설명]
옛날에 도움말은 자신이 찾아야 된다. 내가 무엇을 하다가 도움말을 찾을때 해당 작업에 관계된 도움말이 나온다. context-sensitive help system.
switch문으로 각각 help 를 찾을 수 있게 할 경우?
새로운 help 추가시?
detault로만 빠진다.
도움말 제공 전담 객체를 두는 방식 ...
보다 나은 해결 방법
동적으로 자기가 하는 일을 위임하는 역할을 한다. 위임하는 주체는 정하지 않는다.
하나 이상의 객체가 요청을 처리할 수 있고, 미리 어떤 객체가 요청을 처리할 지 알지 못하며, 실제 요청을 처리하는 객체는 자동으로 결정되어지기를 원할 경우.
구체적으로 수신자를 지정하지 않고 여러 객체들중 하나에게 요청을 전달하고자 할 때
요청을 처리할 수 있는 객들이 동적으로 명시되어져야 할 때
구현상에서 가장 고민 되는 부분이 chain을 어떻게 구성할 것인가!!
하는 부분이다.
컴포지터 패턴이 적용되어있는 경우 (tree형태 인경우) request를 처리할 경우 처리하자 못하는 경우 부보 에게 전달한다. ... 구성관계를 이용하여 chain을 구성할 수 있다.
이미 어떤 구성된 링크가 있을때...
Successor를 어떻게 저장관리 하느냐...
요청의 수만큼 인터페이스를 가지는 방법
그렇지 않다면 ...request id받아서 int 를 ... 처리
<<begin 내가 생각한 chain of responsibility 패턴 이용처 >>
웹에서 querystring이나 post 방식으로 들어오는 값 처리를 생각해보면 되지 않을까...
생각지 않은 방법이 올때는 error 처리하는 것으로 처리하는... 처리를 switch문으로 하는 것이 아니라 동적 type casting으로 하면 되겠지!!
음 톰캣이 이렇게 구현되어 있을까?
전산에서 역사와 이렇게 구현된 프로그램이 있다는 것도 중요하겠지만, 현재 프로젝트를 적용해결하는 것이 우선인 분야임을 다시금 알게된다. 문제를 정의하고 해결법을 찾을때 경험적인 부분에 DP를 활용하는 것이 필요한 점임을 잊지 말자.
<<end>>
[해당 패턴 설명]

[활용한 패턴 정리]
DNS의 동작 과정을 고려해보자.
[구성]
[Session 1] Part1. Orientation 1
[Session 1] Part2. Orientation 2
[Session 1] Part3. Abstract Factory 패턴
[Session 1] Part4. Builder 패턴
[Session 1] Part5. Factory Method 패턴
[Session 1] Part6. Prototype 패턴
[Session 1] Part7. Singleton 패턴
[Session 2] Part1. Adapter 패턴
[Session 2] Part2. Bridge 패턴
[Session 2] Part3. Composite 패턴
[Session 2] Part4. Decorator 패턴
[Session 2] Part5. Facade 패턴
[Session 2] Part6. Flyweight 패턴
[Session 2] Part7. Proxy 패턴
[Session 3] Part1. Chain of Responsibility 패턴
[Session 3] Part2. Command 패턴과 Template Functor
[Session 3] Part3. Interpreter 패턴
[Session 3] Part4. Iterator 패턴
[Session 3] Part5. Mediator 패턴
[Session 3] Part6. Memento 패턴
[Session 4] Part1. Observer 패턴
[Session 4] Part2. State 패턴
[Session 4] Part3. Strategy 패턴
[Session 4] Part4. Template Method 패턴
[Session 4] Part5. Visitor 패턴
[Session 4] Part6. 디자인 패턴 요약 및 적용 방안
Behavioral Patterns 목적 및 유용성
객체들간의 알고리즘이나 역할 분담 방식을 다루는 것
즉, Behavioral Pattern 들은 객체나 클래스의 구조에 대해 다루는 것이 아니라, 그들간의 교류 방식에 대해 다루는 것이다.
실행시간에 추적하기 어려운 복잡한 제어 흐름이 드러나도록 해준다.
따라서 Behavioral Pattern은 우리가 더 이상 복잡한 제어 흐름에 신경쓰지 않고, 객체들간의 교류 방식에 집중할 수 있도록 해줄것이다.
Class Behavioral Patterns vs Object Behavioral Patterns
Class Behavioral 패턴
-클래스간 상속 관계를 이용해 행위 분산이 이루어지도록 하는 것
-대표적으로 Template method 패턴과 Interpreter 패턴이 있다.
Object Behavioral 패턴
-상속 관계보다는 객체들간에 구성 관계를 이용하여 행위를 분산 처리하는 방식
-이때 관건은 한 객체가 어떻게 다른 객체 대해서 아는가 하는 점인데, 만약 모든 객체들이 서로 서로를 알아야 한다면 객체들간의 결합도(coupling)가 증가하여 바람직하지 않을 것이다.
-따라서, Object Behavioral 패턴들은 여러 객체들에게 행위를 분산시키되 객체들간의 결합도를 낮출 수 있는 방식들을 제시할 것이다.
[문제 사례 설명]
옛날에 도움말은 자신이 찾아야 된다. 내가 무엇을 하다가 도움말을 찾을때 해당 작업에 관계된 도움말이 나온다. context-sensitive help system.
switch문으로 각각 help 를 찾을 수 있게 할 경우?
새로운 help 추가시?
detault로만 빠진다.
도움말 제공 전담 객체를 두는 방식 ...
보다 나은 해결 방법
동적으로 자기가 하는 일을 위임하는 역할을 한다. 위임하는 주체는 정하지 않는다.
하나 이상의 객체가 요청을 처리할 수 있고, 미리 어떤 객체가 요청을 처리할 지 알지 못하며, 실제 요청을 처리하는 객체는 자동으로 결정되어지기를 원할 경우.
구체적으로 수신자를 지정하지 않고 여러 객체들중 하나에게 요청을 전달하고자 할 때
요청을 처리할 수 있는 객들이 동적으로 명시되어져야 할 때
구현상에서 가장 고민 되는 부분이 chain을 어떻게 구성할 것인가!!
하는 부분이다.
컴포지터 패턴이 적용되어있는 경우 (tree형태 인경우) request를 처리할 경우 처리하자 못하는 경우 부보 에게 전달한다. ... 구성관계를 이용하여 chain을 구성할 수 있다.
이미 어떤 구성된 링크가 있을때...
Successor를 어떻게 저장관리 하느냐...
요청의 수만큼 인터페이스를 가지는 방법
그렇지 않다면 ...request id받아서 int 를 ... 처리
<<begin 내가 생각한 chain of responsibility 패턴 이용처 >>
웹에서 querystring이나 post 방식으로 들어오는 값 처리를 생각해보면 되지 않을까...
생각지 않은 방법이 올때는 error 처리하는 것으로 처리하는... 처리를 switch문으로 하는 것이 아니라 동적 type casting으로 하면 되겠지!!
음 톰캣이 이렇게 구현되어 있을까?
전산에서 역사와 이렇게 구현된 프로그램이 있다는 것도 중요하겠지만, 현재 프로젝트를 적용해결하는 것이 우선인 분야임을 다시금 알게된다. 문제를 정의하고 해결법을 찾을때 경험적인 부분에 DP를 활용하는 것이 필요한 점임을 잊지 말자.
<<end>>
[해당 패턴 설명]
[활용한 패턴 정리]
DNS의 동작 과정을 고려해보자.
'컴퓨터(InfoTech)' 카테고리의 다른 글
| [DP] 18. Interpreter 패턴 - 36 분 (0) | 2006/02/14 |
|---|---|
| [DP] 17. Command 패턴과 Template Functor - 89분 (0) | 2006/02/13 |
| [DP] 16. Chain of Responsibility Patterns - 42 분 (object behavioral) (0) | 2006/02/09 |
| [DP] 15. Structural Patterns 정리 - 15 분 (0) | 2006/02/08 |
| [DP] 14. Proxy 패턴 - 50 분 (0) | 2006/02/08 |
| [DP] 13. Flyweight 패턴 - 37 분 (1) | 2006/02/07 |



