파사드는 프랑스어로 출입구, 외벽, 겉보기 라는 뜻인데, 이걸 패턴이라고 해야하나 싶을만큼 우리가 잘 쓰고 있다. 사용자에게 복잡한 설계도 대신 개요, 모델하우스만 보여주는것.
기본적으로 객체지향 프로그래밍을 할 때도, 어느정도 관련이 있으면 몇 가지 절차적인 메서드를 한 메서드 안에서 실행한다. 길어지면 자연스럽게 이름 붙여서 함수로 뽑아냈다. 바로 이거다.
서브시스템을 쉽게 이용할 수 있는 고수준 인터페이스를 지원한다. 그리고 얘는 서브시스템클래스를 아무것도 캡슐화 하지 않기 때문에 그냥 편의적으로 세트실행버튼만 여러개 단 편의성 리모콘 같은 클래스이다.
이를테면 거실 전체의 시스템을 통합적으로 조작하는 리모콘.
거실환경=영화시청모드 → 거실등1,2,3을 50%로 on, 스피커0,1,2는 100% 서브스피커는 60%, 모니터 해상도는~~ 이런거 한번에 동작하도록, 원본 인스턴스를 갖고있고 각 실행명령에 대해 미리 프리셋을 모아놓은것.
영화시청모드 변경 후 고급기능은 원래클래스에서 거실등1.setHue(0.3); 으로 이후 세부 조작도 가능함. → 이게 핵심이다. 기존 기능을 건드리지 않는다!
메인은 편의성이고, 추가적 이점은 조작을 모두 파사드클래스로만 이용한다면, 서브클래스가 업데이트되고 사용클래스들이 변경돼도 파사드클래스만 바꿔주면 됨.
카메라 녹화버튼은 동일한데, 핸드폰마다 뭐 렌즈모델도 다르고 초점잡는메서드도 제각각인데 그건 제조사에서 알아서 바꾸는거고 우리는 녹화버튼 눌러서 녹화만 하면 끝인것과 동일
이놈은 대부분 프로그래머가 자기도 모르게 사용하고 있기도 함. (완전히 클래스로 만드는건 별개지만 아무튼)
예를 들면
그림판 클래스의 드로우 클래스
{
enum 그림도구 - 펜,붓, 스프레이 등 클릭했을때 색을 픽셀로 어떻게 표시할지 벡터와 수학으로 작성한 것들. 최소 하나를 선택해야 함
enum 색 - 검,흰,파,녹,빨,등 기본 색이 있고, 개인이 팔레트로 지정한다면 커스텀컬러{rgba}로 직접 지정함
마우스포인터 - 윈도우의 마우스캡처와 현재 그림판 레졸루션 따라서 위치 잡아주고 뭐 함
그림도구.그리기(색,마우스포인터); → 펜 타입에 대해서 마우스포인터 기준으로 연산하고, 색에서 rgba 뽑아서 각각 for 안에서 연산~~~엄청나게 길어질 수 있다.
}
길어지니까 내용을 CalcDraw(색,마우스포인터) 라는 함수로 뽑아주면?
그림도구.그리기 메서드(색,마우스포인터)
{
return CalcDraw(색,마우스포인터) 가 끝이다.
}
원래는 안이 엄청 길었을 텐데 짧게 바꿔짐. 우리가 늘상 하던 것.
클라이언트를 복잡한 서브시스템과 분리하는게 주 목적. 파사드클래스의 단순화된 기능을 실행할 때, 파사드 클래스는 직접 서브클래스의 인스턴스를 가지고 일을 시키는 것 뿐, 캡슐화 시키거나 다른 역할은 하지 않음
홈씨어터는 여러 장치들의 집합인 복잡한 클래스임
일일히 이걸 다 해야됨. 자동화 하고 싶음. 일종의 루틴, 매크로를 만들고 싶은 것.
영화 끌 때 또 반대로 다 해야됨! 시스템 추가되면 다 수정해야됨.
이때 필요한 게 파사드
스마트홈을 구축하는 것과 똑같음
복잡한 작업 모음 프리셋을 하나의 이름으로 제공하는것.
클라이언트는 복잡한 절차를 알 필요 없이 영화모드켜기() 하나로 팝콘튀기고 불켜고 스피커 켜고… 다 함
고급기능 쓰려면 그냥 원래 있던 클래스에 직접 조작하면 됨. 전등2번은 끄던지 마음대로.
얘는 세트메뉴일 뿐이지 원래 개별 클래스를 캡슐화 하는건 아님. 세부사항 대신 권장사항을 먼저 보여주는 일만 함.
알잘딱깔센 해~
피카츄 옆으로 피하고 상대를 똑바로 보고 볼의 전극에 빠르게 전하 축전하고 절연파괴전압에 도달하고&&10만볼트가 되면 전기공격()을 실행해!
-> 피카츄 10만볼트!
얼마나 편해
파사드 인터페이스는 직접 일 안함. 명령 모음일 뿐임. 서브클래스의 원본 인스턴스 모두 가지고 있어서 걔네한테
정해진 프리셋 대로 전달만 할 뿐임.
파사드 여러개를 만들어도 됨. 원본과 별개로 존재하기 때문임. 환경설정 프리셋 100개든 1000개든 아무 상관 없는 것 처럼.
파사드를 적절히 설계한다면, 클라는 파사드로만 서브클래스 컨트롤이 가능한 환경을 만들 수도 있음
이 경우에는 특별히 클라와 서브시스템이 완전히 분리되게 되고, 이렇다면 서브시스템과 파사드만 싹 교체해도
클라 코드는 수정할 필요가 없음
의존성 없애고 시스템과 클라를 분리하는건 보조 목적임
최대 목적은 클라에게 편의성을 높여주는것.
초심지켜라. 클라가 왕이다. 클라가 잘못 호출하면 그건 설계한 프로그래머 잘못이다.
실수 할 가정을 하고 미연에 방지하는게 지금 하는 공부
최소지식 원칙. 복잡->단순. 클라는 필요한 것만 알면 됨.
그냥 간단히 생각해보자 왜 네임스페이스를 나누고 하는지.
사용성도 사용성이지만 길이 단순할 수록 충돌사고가 안나고 리팩토링도 쉽고, 버전관리나 모듈화도 쉬움
한번에 갈 수 있는건 한 번에 가라는 원칙을 따른 패턴.
