객체지향분석및설계 - Facade

안녕하세요. 객툰 제한 분석 및 설계에서 디자인 패턴, 파사드 패턴을 공부하도록 하겠습니다. 파사드 패턴입니다. 파사드라는 것은 정면 현관 같은 거죠. 어떤 시스템에 들어갈 때 맨 처음에 들어가는 엔트리 포인트에요. 시작하는 그 위치를 파사드라고 하죠. 그럼 어떠한 문제에 있어서 파사드가 필요한지를 보도록 하겠습니다. 일반적이고 그리고 정형화된 인터페이스를 제공을 해주는 건데요. 그래서 이 서브 시스템이나 시스템 안에서 외부에서 접근을 할 때 이 내부에 있는 내용을 다 일일이 접근하지 않고 뭔가 유니파이드 된 인터페이스가 필요하다는 것입니다. 그래서 안에 있는 서브 시스템에 너무 많은 것들이 원치 않게 커플링을 하는 것을 막아주는 것이 필요하다는 상황이죠. 그래서 이런 원치 않는 커플링이 있는데 이것을 임플레멘테이션을 할 때 또 이것을 바꿀 때마다 같이 바꿔야 된다. 그럼 어떻게 하겠느냐는 거죠. 거기에 따라서 솔루션은 이 서비스 시스템을 접근을 하려고 할 때 싱글 포인트 컨택을 하라는 거죠. 한 군데에서만 접근을 해서 그 이름을 Fasad Object이라고 얘기할 수가 있습니다. 그래서 하나의 정문 혹은 현관 형태의 Object을 연결을 해서 그쪽으로 서브 시스템을 항상 들어갈 수 있도록 해주고 이 Fasade Object이 내부 서브 시스템을 다 감싸일 수 있도록 해주는 거예요. 그렇다면 내부가 보이지 않고 Fasade Object만 보이게 된다는 겁니다. 그래서 이러한 Fasade Object은 Single Unified Interface, 하나로 정형화된 인터페이스를 나타내 주고요. 그리고 내부에 있는 서브 시스템과 연동을 하는 구체적인 콜라보레이션을 하게 됩니다. 외부에서는 단 하나의 파사드로 들어가고 그리고 파사드에서 내부의 서브 시스템의 콜라보레이션 협업해서 일을 처리하도록 하는 구조입니다. 그래서 파사드 패턴 더 내용을 보도록 하겠습니다. Front End 그래서 클라이언트 혹은 유저 혹은 외부의 유스케이스 시나리오를 시작하는 곳에서 프론트 엔드 오브젯으로 대상 시스템을 들어가는 입구 역할을 하게 됩니다 그래서 이 내부에 있는 임플레멘테이션은 안에 숨겨져 있어요 예를 들어서 프라이빗으로 되어 있어요 그래서 외부에 있는 컴포넌트들이 그 내부에 있는 임플리멘테이션을 볼 수 없도록 하는 것입니다 그래서 이 Fasade는 protected variation을 제공해줘요 그래서 변경이 가능하도록 하는데 제한된 형태에서 변경이 가능하도록 하는 거죠 그래서 서브 시스템에 필요함에 따라서 임플리멘테이션을 할 때 외부에서는 보이지 않고 내부에서만 할 수 있는 Protected Variation을 제공을 해주게 됩니다. Fasad는 example에 있어서 Rule Engine 같은 것들이 거기에 해당돼요. 그래서 Specific한 안에 세부적인 Implementation은 아직 결정되지 않은 상태에서 외부의 요청에 따라서 그 외부의 요청이 무엇인지를 Validate를 하면서 내부에 있는 일들을 처리를 해주는 것을 생각할 수가 있습니다. 그래서 외부에서는 정확하게 내부의 Implementation을 볼 수가 없고 어떤 Implementation은 숨겨진 히든 된 Implementation을 가지게 된다고 보시면 되겠습니다. 그리고 어떤 룰은 오퍼레이션을 처리할 때 적절하지 않은 룰을 처리를 할 수가 있어요 그래서 그런 경우에 이것을 표현할 수도 있다고 보시면 되겠습니다 그러면 여기 세일 클래스를 한번 볼까요 여기서 보면 MakeLineItem이 있어요 그럼 세일 라인 아이템을 새로 만들어 주는 거죠 새로운 어떤 프로덕트를 몇 개 사겠다라는 것을 만들어 주고요 SLI 로 야구잭을 기억을 합니다 그러고 나서 롤 엔진을 돌려주는 거죠 롤 엔진에서 인스턴스를 싱글턴이죠 인스턴스를 하나 물고 와서 is valid 를 하는 거죠 그것은 뭐냐면 이 sale line 아이템이 있는 것이 valid 인지를 체크를 하는 거죠 그래서 만약에 재고가 없다든가 혹은 물건을 우리가 더 이상 취급하지 않은데 그 물건을 사려고 하는 혹은 에러를 낼 수가 있는 상황인지를 한번 valid를 하는 것입니다 valid를 하면 넘어가고 is invalid 잘못되면 return을 하게 되는 거죠. 그런 것이 없습니다. 그리고 valid하면 그것을 add를 해줍니다. 그럴 때 여기서 롤 엔진 같은 것들을 체크하는 것을 파사드로 해주는 거예요. 내부에는 hidden 되고 우리가 있는 object을 던져줘서 그것을 validate를 처리합니다. 유효하는지 안하는지를 체크해서 true false만 던져주게 된다고 보시면 되겠습니다. 그럼 파사드를 가지고 있는 패키지 다이브럼을 보도록 하겠습니다. 그래서 facade는 싱글턴으로 주로 연결이 되곤 해요. 왜냐하면 한 군데 정문으로 들어가는 거기 때문에 이것이 인스턴스가 여러 개면 어떤 인스턴스로 들어갈지가 모호하게 되는 거죠. 그래서 많은 경우에 싱글턴으로 합니다. 그래서 아까 본 것도 싱글턴에 get instance 이런 식으로 하게 되죠. 여기 클릭 있으면 더 좋겠죠. 그래서 도메인에서 어떠한 리퀘스트를 하고 이 룰 엔진을 만들어 놓고 룰에 따라서 valid invalid를 체크를 해서 이것이 적절하면 valid로 해주고 그렇지 않으면 invalid를 리턴을 해주게 된다고 보시면 되겠습니다. 그래서 외부에서 이 Fasad를 통해서 내부는 다 숨겨지게 되는 거에요. 이것은 Hidden 되구요. 외부에서는 이 인스턴트를 받아서 Invalid 한지만 체크를 합니다. 세일 라인 아이템과 페이먼트 요거 정도만 체크를 해주는 거죠. 그래서 룰에 따라서 결정을 해줍니다. 예, Fasad Pattern은 복잡한 인터페이스를 쉽고 간단하게 만들어 줍니다. Fasad Class를 이용해서요. 그래서 간단하게 외부에서 접근할 수 있도록 해주는 거죠. Fasad Pattern은 unified interface 정형화된 형태로 인터페이스를 만들어 줘서 이 서비스 시스템에 있는 인터페이스를 적절하게 정형화 하는 형태로 제공할 수가 있습니다 그 판사는 하이어레벨 인터페이스를 정의 정의 하게 되요 그래서 내부에 있는 시스템의 디테일한 것보다도 좀 더 일반화된 인터페이스를 사용자에게 제공을 한다고 보시면 되겠습니다. 그리고 FAS화된은 복잡하고 로우 레벨의 인터페이스를 더 하나로 만들어줘서 그것을 심플하게 전체의 시스템이 접근될 수 있도록 도와주게 됩니다. 한번 구조를 보면요. 환사하드를 통해서 서브 시스템의 내부가 이렇게 연결이 되는 거죠. 그래서 외부에서는 이렇게 이렇게 하려면 이것을 안에 있는 서브 시스템들을 알아야지만 되는 거잖아요. 그렇게 하지 않고 파사드를 통해서 파사드를 통해서 연결을, 리퀘스트를 하고 파사드에서 그 내용을 가지고 적절하게 인보케이션을 해 나가는 형태입니다 자 그러면 이 example을 보도록 하겠습니다 클라이언트를 이용해서 이 시스템을 접근을 하려고 해요. 그래서 이 시스템은 스케줄링하는 서버예요. 클라이언트가 이를 접근을 하는데 이 안에 스케줄러가 굉장히 복잡한 거죠. 복잡한데 이 서비스를 시작하고 스탑을 하고 싶은데 이것을 가장 간단하게 클라이언트 입장에서 가장 간단하게 하는 것이 무엇일까 라고 고민을 하는 것입니다 그래서 클라이언트가 서버를 외부에서 익스터널 외부에서 얘를 제어하려고 할 때 가장 간단하게 하는 방법입니다 우선 스케줄러 서버가 있는데 스케줄러 서버가 이렇게 New 해서 만들어졌어요. 가장 간단한 방법이 무엇일까요? 한번 내용을 보도록 하겠습니다. 이것이 간단한 건지 한번 보도록 할게요. 워낙 이 스케줄 서버는 이런 식으로 순차적인 일들이 진행이 돼요. Start booting 하고요. Ready system configuration file. 있는지를 다 확인 밸리데이트를 하고 다 준비를 하죠. 이닛 시키고, 이니셜의 컨텍스트를 하고, 이니셜의 리스너들을 다 띄워두고, 그리고 시스템 오브젝트를 다 만들어 줍니다. 그러고 나서 이제 시작합니다. 이런 식으로 메시지를 하는 것이 시작하는 단계에요. 그럼 클라이언트가 이거를 다 기억을 해야 되겠죠 하나씩 다 시스템 스케줄 서버를 시작을 하려면 이런 일들을 다 기억을 해서 이대로 해줘야지 된다는 거죠 이것이 간단할까요? 자 또 다른 게 있습니다 스탑을 하는 거예요 스탑을 하는 것도 프로세스를 다 릴리즈를 시켜서 메모리에다 이제 릴리즈를 해주고 디스트로이 해주고 디스트로이 시스템 오브젝을 해주고 리스너들을 다 이제 끝내주고 컨텍스트를 다 디스트로이 해주고 셧다운을 합니다 이것이 정상적으로 이 스케줄러 서버를 스탑 시키는 방법이에요 그러면 이 클라이언트가 이 모든 것을 순차적으로 그대로 해줘야 된다는 거죠. 그런데 하나라도 잘못되면 제대로 작업이 안 되고 메모리 랭킹 현상이 일어납니다. 그렇게 해서 우리가 FACAD를 한다는 것은 뭐냐면은 이 모든 시퀀셜 한 오프레이션들을 래핑을 해줘요. 감싸줘요. 그래서 외부에서는 start 서버만 불러주고 stop 서버만 불러주는 거예요. 그래서 이 스케줄러 서버가 하는 일이 new 여기 스케줄러 서버가 있죠. 파사드로 랩핑을 해주는 거죠 그래서 이 파사드를 object을 만들게 되면 여기에서 scheduler 서버에 attribute 여기다 집어넣고 starthera 이 object. 예를 들어서 start server 그럼 이 schedule 서버를 구르면서 우리가 해야 되는 세컨스를 순차적으로 액티베이션 하는 거고요. 그 다음에 이 object.stop 서버 하게 되면 이 스케줄에 관련된 일을 순차적으로 스탑을 하는 일들을 합니다. 그러면 외부에서 이 스케줄 서버를 관리하기가 무척 쉬워지게 된다. 라고 보시면 되겠습니다 한번 보시면 스케줄 서버를 하나 만들었어요 그리고 파사이드에다가 얘를 넘겨줘요 그러면 facade object.start server 하면 start가 되구요 끝날때는 facade server에 stop server 이런식으로 하게 되면 외부에서는 내부에 어떤 절차를 밟으면서 stop을 해야 되는지 혹은 start를 해야 되는지를 고민하지 않고 method만 부르게 되는 형태를 가지고 있습니다.