[수정중] 헤드퍼스트 디자인 패턴 [7]
헤드퍼스트 디자인 패턴[7]
- 어댑터 패턴 & 퍼사드 패턴
어댑터: 한 인터페이스를 다른 인터페이스로 변환시켜주는 역할을 수행.
객체지향에서도 비슷하게 받아들이면 된다. 다시말해 클라이언트로부터 요청을 받아서 새로운 업체에서 제공하는 클래스(서드파티 클래스)에서 받아들일 수 있는 형태의 요청으로 변환시켜주는 중개인 역할을 수행한다.
1장에서의 duck 인터페이스를 통해 다시 봅시다.
클라이언트: 타깃 인터페이스에 맞게 구현되어있음. 즉, 어댑터와 호환됨.
어댑터: 타깃 인터페이스를 구현하며, adaptee 인스턴스가 있다.
adaptee: ducks에서는 Turkey가 adaptee 인터페이스.
(adaptee: 어댑터를 중간에 두고 클라이언트와 정 반대의 위치에 있는 것. adapter에게서 adapt받는 놈)
- 클라이언트에서 어댑터를 사용하는 방법
- 클라이언트에서 타깃 인터페이스를 사용하여 메소드를 호출함으로써 어댑터에 요청함.
- 어댑터에서는 adaptee 인터페이스를 사용하여 그 요청을 어댑티에 대한 (하나 이상의) 메소드 호출로 변환함.
- 클라이언트에서는 호출 결과를 받는다. 다만 클라이언트는 어댑터가 있는지는 모른다. 알 필요도 없다.
클라이언트와 어댑터는 분리되어있다! 서로 상대방에 대해 모름.
나머지는 소스코드의 주석으로 이해하도록 하자.
이것이 바로 어댑터 패턴!
어댑터 패턴: 한 클래스의 인터페이스를 클라이언트에서 사용하고자 하는 다른 인터페이스로 변환한다. 이를통해 인터페이스 호환성 문제 등 같이 쓸 수 없는 클래스를 연결해서 쓸 수 있다.
책 내용 좀 다시 봐야할듯..
어댑터 실전 예제:
Enumeration, Iterator가 바로 그것.
Enumeration: 초기 컬렉션 형식의 것들에 대해 hasMoreElements(), nextElement() 를 수행.
Iterator: 위의꺼와 유사. hasNext(), next(), remove() 등이 가능.
---
퍼사드 패턴: 인터페이스를 간단하게 바꿈.
뭐하고 뭐하고... 이런걸 일일이 함수로 호출할 것이 아니라 한번에 쉬운녀석으로 호출하면 일일이 해야하던걸 모두 호출시키게 함.
- 구성요소에 대한 서브시스템화를 통해 기존의 함수 호출을 모음
- 퍼사드에 있는 메소드를 호출하면 서브시스템의 함수들이 모두 호출됨 -> 인터페이스 관리가 쉬워짐
- 퍼사드를 쓰더라도 서브시스템에는 여전히 접근 가능
이것이 바로 퍼사드 패턴!
퍼사드 패턴: 어떤 서브시스템의 일년의 인터페이스에 대한 통합된 인터페이스를 제공한다. 퍼사드에서 고수준의 인터페이스를 정의하기 때문에 서브시스템을 좀 더 쉽게 사용할 수 있게 된다.
퍼사드 패턴은 중요한 디자인 원칙을 일러준다.
객체 사이의 상호작용은 될 수 있으면 아주 가까운 "친구" 사이에서만 허용하여야 함.
----------------------------------------------------------
| 디자인 원칙 - 7 : 최소 지식 원칙 - 정말 친한 친구하고만 이야기하라. |
----------------------------------------------------------
시스템을 디자인할 때, 어떤 객체든 그 객체와 상호작용을 하는 클래스의 갯수에 주의하여야 함. 그런 객체들과 어떤 식으로 상호작용을 하는지에도 주의를 기울여야 함.
여러 객체와 인연을 맞는것을 최소화하려면? 어떤 메소드이든 간에 다음 4종류의 객체의 메소드만 호출하면 된다.
- 객체 자체
- 메소드에 매개변수로 전달된 객체
- 그 메소드에서 생성하거나 인스턴스를 만든 객체
- 그 객체에 속하는 구성요소 (A에는 B가있다 관계의 객체)
좀 까다롭긴함... 책 보고 한번 더 이해햐기