Topic 29 실세계를 갖고 저글링하기
데이비드 토머스, 앤드류 헌트
느낌표 ! (인상 깊은 문장 | 문맥)
어떻게 이벤트에 잘 반응하는 애플리케이션을 만들 수 있을까? 아무 전략이 없다면 우리는 금방 혼란에 빠질 것이고, 우리의 애플리케이션은 서로 긴밀하게 얽힌 엉망진창 코드 덩어리가 되고 말 것이다. 우리를 도와줄 네 가지 전략을 살펴보자.
- 유한 상태 기계
- 감시자(observer) 패턴
- 게시-구독
- 반응형 프로그래밍과 스트림
p.194
이벤트를 처리할 때 콜백 함수로 처리를 당연하게 처리하곤 했는데 이처럼 다양한 방식을 염두하고 고려하지는 않았었다. 이처럼 다양하게 고려를 할 때 같은 선택지를 선택하더라도 결과물이 달라질 것이다.
감시자 패턴
‘감시자 패턴’은 이벤트를 발생시키는 쪽인 ‘감시 대상’과 이런 이벤트에 관심이 있는 클라이언트인 ‘감시자’로 이루어진다.
p.199
감시자 패턴에는 문제가 하나 있다. 모든 감시자와 감시 대상에 등록을 해야 하기 때문에 결합이 생긴다. 더군다나 일반적으로 감시 대상이 콜백을 직접 호출하도록 구현하기 때문에 이 부분이 성능 병목이 될 수 있다. 동기적 처리의 특성상 콜백 실행이 끝날 때까지 감시 대상이 계속 기다려야 하기 때문이다.
p.200
감시자 패턴의 단점으로 성능 병목을 설명하고 있는데 아직 몸소 경험해보지는 않았다. 대용량 트래픽과 데이터를 경험해보고 싶다.
게시-구독
게시-구독 혹은 발행-구독 모델은 줄여서 펍섭(pubsub)이라고도 부르며 감시자 패턴을 일반화한 것이다. 동시에 감시자 모델의 결합도를 높이는 문제와 성능 문제도 해결한다.
p.201
게시-구독 모델을 알고 있었는데 감시자 패턴과 매우 유사한데 무엇이 다른지 찾아보지를 않았었다. 역시 궁금했을 때 바로 찾아보는 것이 가장 좋은 것 같다.
각 채널에는 이름이 있다. 구독자는 관심사를 하나 이상의 채널에 등록하고, 게시자는 채널에 이벤트를 보낸다. 감시자 패턴과는 다르게 게시자와 구독자 사이의 통신은 여러분의 코드 밖에서 일어난다. 아마 비동기적으로 이루어질 것이다.
p.201
대신 단점은 게시-구독 모델을 아주 많이 사용하는 시스템에서는 현재 어떤 일이 벌어지고 있느지 파악하기가 힘들다는 것이다.
p.202
뭐든 장점과 단점이 있듯 상황에 따라 잘 판단해서 감시자 패턴, 게시-구독 모델을 잘 선택해야할 것이다.
반응형 프로그래밍과 스트림 그리고 이벤트
스트림은 이벤트를 일반적인 자료 구조처럼 다룰 수 있게 해 준다. 이벤트의 리스트를 다룬다고 생각하면 된다. 새로운 이벤트가 도착하면 이 리스트가 길어지는 셈이다. 이런 방식이 좋은 이유는 익숙한 방식으로 스트림을 다룰 수 있기 때문이다. 이벤트를 처리하고, 조합하고, 골라내는 등 우리가 아는 온갖 작업을 일반적인 자료 구조와 마찬가지 방법으로 할 수 있다. 심지어 이벤트 스트림과 일반 자료 구조를 조합할 수도 있다. 또한 스트림으느 비동기적으로 작동할 수도 있는데, 이벤트가 도착했을 때 여러분의 코드가 이벤트에 응답할 기회를 얻는다.
p.202-203
책에 설명되어 있는 반응형 프로그래밍의 예제를 보면 당장이라도 사용해보고 싶은 욕구가 든다. 매우 깔끔하게 코드를 작성할 수 있는 것을 보았기 때문이다. 다음 책은 RxJs 보려한다.
어디에나 이벤트가 있다.
이벤트가 어디서 발생하든 이벤트를 중심으로 공들여 만든 코드는 일직선으로 수행되는 코드보다 더 잘 반응하고 결합도가 더 낮다.
p.206
저자는 이벤트가 꼭 버튼을 누른 것만이 아니라 데이터를 불러오고, 내부 계산 결과 등도 이벤트라고 설명하고 있다. 이러한 이벤트 관점에서 코드를 볼 때 진짜 세상에서 더 잘 작동하는 애플리케이션이 탄생할 것이라고 설명하고 있다.
Topic 29 느낌
Topic 29 에서는 이벤트 관점에서 바라보고 코드를 작성하는 방법을 설명하고 있다.