[채팅앱][클라이언트] EventHandler 클래스 및 아키텍처 수정

(갤럭시 탭을 구입해서 처음 작성해서 올리는 그림이다. 지금까지 직접 필기한 그림을 올리거나 마우스로 그림판에 그려 올렸는데 삶의 질이 올라간 기분!!)

 

EventController와 같은 컨테이너 클래스를 둔 이유

결론부터 말하자면 핸들러의 유지보수성 때문이다.

 

지금 당장은 콘솔을 기반으로 한 채팅앱이라 EventHandler 의 핸들러가 처리한 결과를 바로 콘솔에 띄워서 바로 반영할 수 있다. 하지만 이 앱이 GUI 기반의 앱으로 확장될 가능성이 있다면?

핸들러에서 처리한 결과를 어떻게든 반영하기 위해 핸들러는 UI 객체에 대해 알아야 한다. UI를 컨트롤하는 객체는 main context에서 객체를 생성할 터인데 이를 주입받아 이벤트 컴포넌트 들과의 관계들을 설정하는 컨테이너 객체도 필요한 것이다.

 

이벤트 컴포넌트 객체들은 모두 EventController에서 생성되고 주입된다. 그리고 EventController 클래스는 main context 등에서 이벤트 컴포넌트에 접근할 수 있게 하는 적절한 api와 객체들을 반환한다.

 

그런 이유로 이전에는 EventLoop 에서 EventHandler 객체를 생성했는데, 이것도 객체를 주입받는 걸로 수정했다.

 

EventHandler 에서 핸들러에 대한 개념 수정

'핸들러에 대한 개념'이라고 추상적으로 말하긴 했지만(사실 콕 집어 말하기가 애매했다), 메서드의 레벨이나 깊이가 변했다고 말할 수도 있을 것 같다.

 

지난 설계에서 핸들러들은 SelectionKey의 operation(ACCEPT, CONNECT 등)에 1:1 대응하는 개념이었다.

이렇게 하면 확장성있게 대응할 수 없다. 같은 operation 이라도 IO 작업 후의 작업에 따라 다른 핸들러를 작성해야 할 수도 있기 때문이다. 

 

그래서 operation에 대한 기본 코드들을 따로 분리했다.

핸들러는 이를 적절하게 호출해 사용하고, 후작업까지 할 수 있는 한단계 높은 context의 메서드로 수정했다.

 

그리고 핸들러의 매핑을 위해 @Event 에 기존의 eventType을 eventName:String 를 인수로 대체했다.

 

이제 다시 코드를 작성해보자!!(몇 번 뒤집어 엎었다.)