디자인 패턴 - 퍼사드 패턴(Facade pattern)

퍼사드 패턴

정의 : 어떤 서브시스템의 일련의 인터페이스에 대한 통합된 인터페이스를 제공한다. 고수준 인터페이스를 정의한다.

클라이언트를 복잡한 서브시스템과 분리시켜주는 역할을 한다.
구성을 통해 퍼사드에서 서브시스템에 있는 모든 구성요소에 접근할 수 있게끔 한다.
퍼사드 클래스는 서브시스템 클래스들을 캡슐화하지 않는다. 그냥 서브시스템 클래스의 기능을 사용할 수 있는 간단한 인터페이스만 제공한다.

어댑터 패턴은 인터페이스를 변경해서 클라이언트에서 필요로 하는 인터페이스로 적응시키기 위한 용도.
퍼사드 패턴은 어떤 서브시스템에 대한 간단한 인터페이스를 제공.

예시:
SubSystemOne, SubSystemTwo, SubSystemThree
AFacade{ DoSomething(){ SubSystemOne.Do1(); SubSystemTwo.Do2(); SubSystemThree.Do3(); }
Client.AFacade.DoSomething(); // All subsystem of facade do their job.

댓글

댓글 쓰기

이 블로그의 인기 게시물

디자인 패턴 - 더티 플래그(Dirty flag)

계속해서 변경되는 ' 기본값 '이 있다. 또한 ' 파생값 '은 기본 값에 비싼 작업을 거쳐야 얻을 수 있다. 더티 플래그는 파생 값이 참조하는 기본 값의 변경 여부를 추적한다. 즉 더티 플래그는 기본값이 변경되면 켜진다 . 파생값을 써야 할 때, 더티 플래그가 켜져 있다면 다시 계산한 뒤에 플래그를 끈다 . 만약 플래그가 꺼져 있다면 이전에 캐시해놓은 파생 값을 그대로 사용 한다. 어떤 값이 더 이상 맞지 않다는 뜻으로 '더티'하다고 칭한다. 플래그란 둘 중 하나의 상태만 될 수 있는 작은 데이터를 뜻한다. 깨끗하지 않은 상태를 플래그로만 표시하고 그때그때 계산하지 않고 최종적으로 더티 플래그로 표시된 값들만 계산함으로써 중복된 계산을 피할 수 있다. 주로 계산과 동기화 작업에 사용할 수 있다. 사용 조건 파생 값이 사용되는 횟수보다 기본 값이 더 자주 변경되어야 한다. 점진적으로 업데이트하기가 어려워야 한다. 주의. 상당한 시간이 걸리는 작업을 지연해놨다가 결과를 보고 싶어 할 때 처리를 시작한다면, 짜증나는 랙이 생길 수 있다.
자세한 내용 보기

디자인 패턴 - 서비스 중개자 패턴(Service locator pattern)

서비스를 구현한 구체 클래스는 숨긴 채로 어디에서나 서비스에 접근할 수 있게 한다.  객체나 시스템 중에 거의 모든 코드에서 사용되는 것들이 있다. 이런 시스템은 게임 전체에서 사용 가능해야 하는, 일종의 서비스 라고 볼 수 있다.(메모리 할당, 로그, 난수 생성 등) 서비스를 사용하는 코드로부터 서비스가 누구인지 (서비스를 구현한 구체 클래스 자료형이 무엇인지), 어디에 있는지 (클래스 인스턴스를 어떻게 얻을지)를 몰라도 되게 해준다. 서비스는 여러 기능을 추상 인터페이스로 제공한다. 구체 서비스 제공자 (Service provider)는 이런 서비스 인터페이스를 상속받아 구현 한다.  이와 별도인 서비스 중개자 (Service locator)는 서비스 제공자의 실제 자료형과 이를 등록하는 과정은 숨긴 채 적절한 서비스 제공자를 찾아 서비스에 대한 접근을 제공 한다. 서비스 중개자는 서비스 제공자를 등록하고, 서비스를 사용하는 측에서 이 서비스를 이용할 수 있도록 중개해준다. 서비스 등록은?  외부 코드에서 등록할 수도 있고, 컴파일 시 바인딩될 수도 있다. 런타임에 설정 값을 읽을 수도 있다. 서비스를 못 찾으면?  사용자가 알아서 처리. 혹은 단언문으로 게임을 멈춤. 널 서비스 반환. 서비스 범위는?  전역(언제 어디에서 사용되는지 제어 불가)  특정 클래스로 제한(커플링 제어 가능. 중복 가능성) 사용처 :  접근해야 할 객체가 있다면 전역 메커니즘 대신  필요한 객체를 인수로 넘겨줄 수 없는지 부터 봐야 한다. 쉽고 커플링을 명확히 보여줄 수 있다.  렌더링 함수 매개변수에 렌더링에 관련된 것만 있어야지 로그 같은 게 섞여 있으면 곤란하다.  어떤 시스템은 본질적으로 하나뿐이다. 대부분의 게임 플랫폼에 오디오나 디스플레이 시스템이 딱 하나만 있다.  서비스 중개자는 일종의 더 유연하고 더 설정하기 좋은 싱글턴 패턴이다.  유연성을 얻지만, 코드만 보고 어떤 의존성을 사용하는지 알기 어렵다.
자세한 내용 보기

인공지능 - 유한 상태 기계(Finite state machine)

FSM은 기초적이지만, 아주 유용하게 쓰일 수 있다. 점점 행동 트리(Behavior tree)나 계획 시스템(Planning system)을 많이 쓰는 추세지만, 다음과 같은 특정 문제 해결을 위한 모델링으로써는 충분하다. 내부 상태에 따라 객체 동작이 바뀔 때 이런 상태가 그다지 많지 않은 선택지로 분명하게 구분될 수 있을 때 객체가 입력이나 이벤트에 따라 반응할 때 게임 AI로도 이용되지만, 입력 처리, 메뉴 화면 전환, 문자 해석, 네트워크 프로토콜, 비동기 동작 등을 구현하는 데에도 많이 사용된다. 유한 상태 기계(Finite state machine) 가질 수 있는 '상태'가 한정된다. 한 번에 '한 가지' 상태만 될 수 있다. '입력'이나 '이벤트'가 기계에 전달된다. 각 상태에는 입력에 따라 다음 상태로 바뀌는 '전이'가 있다. 스테이트 패턴 은 유한상태기계를 구현하는 방법 중 하나이다. 순수하게 형식만 놓고 보면, '상태, 입력, 전이'가 FSM의 전부다. 상태 객체에 필드가 따로 없다면 정적 객체로 만들어 쓰면 된다. 상태 기계는 엄격하게 제한된 구조를 강제함으로써 복잡하게 얽히는 코드를 정리할 수 있게 해 준다. 그러나 FSM에는 미리 정해놓은 여러 상태와 현재 상태 하나, 하드코딩된 전이만 존재한다. 그러므로 유한상태기계를 인공지능같이 더 복잡한 곳에 적용하다보면 한계에 부딪히게 된다. 병행 상태 기계  여러 상태를 각각 참조해서 사용한다. 예를 들어 플레이어 캐릭터가 무엇을 하고 있는가, 플레이어 캐릭터가 무엇을 들고 있는가 등으로 나눠서 병행으로 들고 있는 것이다.  두 상태 기계가 서로 연관이 없다면 잘 맞는 방법이다. 그러나 서로 상호작용하기 시작하면 지저분해진다. 계층형 상태 기계 상태 기계를 객체지향 코드라고 생각하고, 상속으로 여러 상태가 코드를 공유하게끔
자세한 내용 보기