디자인 패턴(Desine Pattern)
디자인 패턴은 일상에서 패턴은 되풀이되는 사건이나 물체의 형태를 뜻한다. 프로그래밍 세계에서 디자인 패턴은 설계간 자주 발생하는 문제에 대한 일종의 모범답안 혹은 공략집이라고 할 수 있습니다.
디자인 패턴을 사용해야 하는 이유
1. 검증된 해결책
문제가 생겼다고 답을 만들기보다, 이미 만들어둔 답을 적용하면 두번 일 하지 않고 생산성을 높일 수 있습니다. 또한, 이미 검증된 방식으로 구현된 구조를 활욜 한다면, 내가 작성한 코드의 문제점도 검증된 방법으로 해결방안을 찾을 수 있어, 효과적으로 코드를 개선할 수 있다는 장점도 있습니다.
2. 효율적인 소통방식
디자인 패턴은, 복잡도가 높아지는 상황에서 팀이 해야할 일을 매번 장황하고 디테일한 설명을 거치지 않고, 사전에 약속해 둔 용어들로 표혀할 수 있도록 도와줍니다. 사전에 약속해둔 용어로 표현한다는건, 설명을 덜 하면서 의미를 명확히 하고 효율을 높이고, 체계적인 코드를 만들 수 있다는 것 입니다.
3. 유지보수 용이
각각의 기능을 담당하는 영역을 분리해서 관리하도록 설계 되어있어 수정이 필요한 부분만 필요한 시점에 유지보수하기 용이합니다.
MVC(Model-View-controller)
프로젝트의 구성 요소를 역할에 따라 Model, View, Controller 세 가지 구조로 나눠서 관리하는 패턴이다
- Model은 정보, 데이터를 관리하는 역할. React의 경우 state가 될 수 있습니다.
- View는 브라우저 화면, 사용자 인터페이스 요소를 담당합니다. React에선 JSX가 될 수 있습니다.
- Controller는 사용자의 Action에 의해 이벤트를 감지하고 처리하는 역할을 합니다. Model 또는 View를 업데이트하는 로직을 포함합니다.
사용자에 의한 Action이 일어나면, Controller가 감지해 Model에게 데이터를 바꿔라고 요청하고, 바뀐 데이터는 View에 반영됩니다. 또한 View에서 Model을 이용해 업데이트를 할 수 있고, 바뀐 모델로 또 다른 View가 업데이트 될 수 잇습니다.
그래서 문제가 생기더라고 어떤 부분에서 발생한 문제인지 비교적 빠르게 확인하고 수정할 수 있습니다. 이러한 효과는 유비보수 및 확장의 용이함 / 중복코드 제거로도 바꾸어 생각해 불 수 있습니다. 이를 관심사의 분리(SoC, Separation of Concern) 라고도 합니다.
하지만, 프로젝트의 단위가 커지면, 자연스레 Model과 View가 늘어가고, 그로인해 의존도가 높아지면서 결국엔 얽히고 섥히게 됩니다. 결국 View와 Model의 업데이트는 예ㅡㄱ하기 어려워 집니다.
Flux
Facebook에서 chat 시스템을 운영하면서, chat 화면이 커지면서, 여러 View에 여러 Model들이 의존하고, 양방향으로 데이터를 주고받는 MVC는 관리하기 어려워겼습니다.
이런 예측하기 어려운 양방향 데이터흐름(Bidirectional data flow)을 보완하기 위해 단방향 데이터 흐름(Unidirectional data flow) 패턴인 Flux를 내놓습니다.
- Action은 이벤트를 구독하고 있다가 이벤트 발생 시 Action 객체를 만들어서 Dispacher에 전달하는 역할을 하는 Acrioin Creator의 역할을 합니다.
- DisPatcher은 Action 객체의 type property에 따라 store에 어떤 행동을 할지 결정합니다. Store의 콜백을 등록하는데 쓰이고, Action을 Store에 배분해줍니다.
복잡한 로직이 있지 않고 Flux의 중앙 허브역할을 합니다. - Store는 상태를 저장하는 저장소의 역할을 합니다. 그리고 상태를 변화시키는 로직을 갖고 잇습니다.
- View는 Store의 상태에 따라 화면에 그러지는 부분입니다.
Flux의 데이터 흐름음 한 방향으로 흐릅니다.
이벤트가 발생하면, Dispather에게 생성된 Action 객체를 전달합니다. Action 객체를 전달밪은 Dispatcher에서 Action 객체의 type property에 따라 Store의 상태를 업데이트 하고, View는 업데이트 된 State에 따라 화면에 그려지는 플로우로 진행됩니다.
마지막 view에 다다르고 화면이 렌더링 되면 view에서 새로운 action 객체를 만들어 시스템에 전파해 업데이트 된 내역을 알게 합니다. 결국 데이터는 한쪽 방향으로만 흐르게 되고, 각각의 구조는 서로 의존하기않고 있어서 데이터 구조파악과 흐름을 예측하기 비교적 용이합니다. 그리고 디버깅에도 어떤 부분의 오류인지 찾아가기 수월한 장점이 있다.
