[DP] 08. Adapter 패턴 - 70 분

[구성]
[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. 디자인 패턴 요약 및 적용 방안

[문제 사례 설명]
하나의 언터페이스를 여러 가지 다양한 형태로 구현해야 한다고 하자.

[패텬을 활용한 해결 방식]/[해당 패턴 설명]
adapter 패턴의 경우는 어떻게 알아서 선택했는가?

하나의 클래스에 인터페이스와 구현을 같이 가지고 있는 경우
bridge 패턴을 사용해서 ... 확장에 용이하다.

=> 이것은 설계의 기본이 아닐까 한다.
내가 클래스를 만들때도 인터페이스 클래스를 만들고 구현은 상속받아서 해결해야 된다.
(자바입장에서 적은 것임)

유닉스 쪽의 so 라이브러리나 원도의 dll로 되어 있는 경우는 컴파일과 링크를 바꿔줄 필요가 없으나
위 경우가 아닌 경우엔 링크는 바꾸어주어야 한다.

이것 때문에 버전닝 인터페이스가 기억난다. (원도의 COM 기술에서 )
듣다보면 원도의 COM 기술을 통해 이해가 된다. 패턴이란 용어를 사용하지 않고도
MS는 이 방법을 쓰고 있었던 것이다.


그러므로 그 기술이 성숙된 회사는 MS 정도가 되지 않을까 한다.
물론 내가 알지 못하는 꽤 나은 소프트웨어 회사가 있겠지만...

client에서 interface 클래스에서 ... 어떤 상속된 클래스를 이용할지 결정할 수 있는가?
새로운 구현 클래스가 나타났을때 어떻게... 항상 동적으로 할 수 없지 않은가?
성능에 따라 어떤 기준에선 구현클래스를 다르게 이용할 경우?

array는 static 영역에 잡힌다.


=> abstract factory와 비슷하게 위임해서 결정하는 법과
=> client 자체가 지정하는 방법 두가지가 있다.

구조만 보면 adapter 패턴중 object 방식과 별 다를게 없다.
목적이 틀리다.
adapter 는 이미 구현된 객체가 있는 경우이고, (사후 약방문)
bridge 경우는 설계시 사전 접근 방법이다.
adapter class 방식은 정적인 결정이 되어버린 상황.

패턴은 구조로 따지면 헷갈린다.
사용하는 목적으로 구분하면 이해가 빠를 것이다. (=>이런게 know-how겠지!!)

[활용한 패턴 정리]

JDBC / ODBC 이런게 bridge 패턴이라고 할 수 있겠다.
표준을 bridge 패턴이라고 할 수 있겠다. 이건 거시적인 측면임을 기억할 것.
Posted by iarchitect