[헤드퍼스트 디자인패턴] 22일차. 294-304pg

22일차

헤드퍼스트 디자인패턴 [4주차_목요일]

294-304pg

요약

CHAPTER 07. 적응시키기 (feat. 어댑터 패턴과 퍼사드 패턴)

• 실제와 다른 인터페이스를 가진 것처럼 보이도록 객체를 감싸면, 특정 인터페이스가 필요한 디자인을 다른 인터페이스를 구현하는 클래스에 적응시킬 수 있다.
• 객체를 감싸서 인터페이스 단순화하기

[퍼사드 패턴 작동원리]

• 홈시어터 시스템용 퍼사드 만들기
• 홈시어터 구성요소 = 하나의 서브시스템으로 간주
• watchMovie()는 서브시스템의 메소드를 호출해서 필요한 작업 처리
• 클라이언트 코드는 서브시스팀이 아닌 홈시어터 퍼사드에 있는 메소드 호출
• watchMovie() 호출 : 조명, 스트리밍, 프로젝터 등등이 알아서 준비됨.
• 퍼사드를 쓰더라고 서브시스템에 접근 가능

 

• 퍼사드 클래스는 서브시스템 클래스를 캡슐화하지 않는다.
• 서브시스템의 기능을 사용할 수 있는 간단한 인터페이스를 제공한 뿐.
• 특정 서브시스템에 대해 만들 수 있는 퍼사드의 개수에는 제한이 없다.
• 클라이언트 구현과 서브시스템을 분리할 수 있다.
• 어댑터와 퍼사드의 차이점은 감싸는 클래스의 개수에 있는 것이 아니라 용도에 있다
  • 어댑터 패턴은 인터페이스를 변경해서 클라이언트에서 필요로 하는 인터페이스로 적응시키는 용도
  • 퍼사드 패턴은 어떤 서브시스템에 대한 간단한 인터페이스를 제공하는 용도

 

 

[ 퍼사드 패턴 정의 ]

서브시스템에 있는 일련의 인터페이스를 통합 인터페이스로 묶어준다.

또한 고수준 인터페이스도 정의하므로 서브시스템을 더 편리하게 사용할 수 있다.

** 패턴의 용도 : 퍼사드 패턴은 단순화된 인터페이스로 서브시스템을 더 편리하게 사용하려고 쓰인다는 사실.

 

 

[ 객체 지향 원칙 : 최소 지식 원칙 (Principle of Least Knowledge) ]

객체 사이의 상호작용은 될 수 있으면 아주 가까운 ‘친구’사이에서만 허용하는 편이 좋다.

• 진짜 절친에게만 이야기해야 한다.
• 시스템을 디자인 할 때 어떤 객체든 그 객체와 상호작용을 하는 클래스의 개수와 상호작용 방식에 주의를 기울여야 한다.
• 친구 만들지 않는 가이드라인 4가지
  • 객체 자체
  • 메소드에 매개변수로 전달된 객체
  • 메소드를 생성하거나 인스턴스를 만든 객체
  • 객체에 속하는 구성 요소 (여기서 구성요소는 인스턴스 변수에 의해 참조되는 객채를 의미함. 즉, A에는 B가 있다.)

  // 원칙을 따르지 않은 경우
  public float getTemp() {
  	Thermometer thermometer = station.getThermometer();
  	return thermometer.gettemperature();
  }
  

  // 원칙을 따른 경우 - 의존해야 하는 class 개수 줄이기
  public float getTemp() {
  	return station.getTemperature();
  }
  

• 데메테르의 법칙 == 최소 지식 원칙 같은말임
• 장점 ) 객체 사이의 의존성을 줄일 수 있으며 소프트웨어 관리가 더 편해진다.
• 단점 ) 메소드 호출을 처리하는 ‘래퍼’ 클래스를 더 만들어야 할 수 도 있다. 그러면 시스템이 복잡해지고 개발 시간도 늘어나고 성능도 떨어진다.

 

 

발췌

💡 퍼사드 패턴의 대표 장점 : 단순화된 인터페이스를 제공하면서도, 클라이언트에서 필요로 한다면 시스템의 모든 기능을 사용할 수 있도록 해준다.

💡 퍼사드 패턴 정의 : 서브시스템에 있는 일련의 인터페이스를 통합 인터페이스로 묶어준다. 또한 고수준 인터페이스도 정의하므로 서브시스템을 더 편리하게 사용할 수 있다.

💡 객체 지향 원칙 : 최소 지식 원칙 (Principle of Least Knowledge) : 시스템을 디자인 할 때 어떤 객체든 그 객체와 상호작용을 하는 클래스의 개수와 상호작용 방식에 주의를 기울여야 한다.