객체지향 프로그래밍은 프로그램을 상호작용하는 객체들의 집합으로 바라보는 것이고, 함수형 프로그래밍은 상태 값을 지니지 않는 함수값들의 연속으로 바라보는 것이다.
e.g. 지동설, 천동설
패러다임을 알고 있어야 하는 이유
잘 만들어진 프로그래밍 패러다임은 보다 좋은 프로그램을 만들 수 있는 방법과 시각을 제공한다.
이것이 객체지향 프로그래밍, 함수형 프로그래밍 등의 패러다임을 배우는 이유이다.
반응형 프로그래밍 패러다임
[!note]
반응형 프로그래밍도 객체지향, 함수형 프로그래밍과 같이 프로그래밍을 바라보는 관점이자 결정을 하는 역할을 하는 하나의 방법론이다.
반응형 프로그래밍이란 데이터의 흐름과 변경사항의 전파에 중점을 둔 선언적 프로그래밍 패러다임이다.
스프레드 시트
반응형 프로그래밍을 가장 쉽게 이해할 수 있는 예시
-
A
B
C
D
1열
1
2
=A1+B1
=A1+B1+C1
C와 D열에는 수식을 선언적으로 작성해 둠
A1, B1의 값을 변경하면 즉시 변경사항이 전파 -> C1의 값이 자동으로 변경됨
C1이 변경되자, D1에도 수식이 반영되어 값이 변경됨
어떤 순서로 데이터가 변경되어야 하는지 정해주지 않았음에도 하나의 데이터의 흐름이 만들어짐
패러다임의 전환
1. 선언적 프로그래밍
무엇을 해야 할지 따로 약속(표현)을 만들어 기술하게 함
언제 어떻게 동작하는지는 내부에서 결정하고 처리함(내부 메커니즘은 숨긴다는 의미)
무엇을 해야 할지 선언을 해두면 내부적으로 알아서 적절하게 렌더링을 하는 방식(e.g. Web)
명령형 vs 선언적
명령형
선언적
어떻게 하는지 알고리즘을 묘사
무엇을 해야 하는지 묘사
시간 순서대로 작성
언제 어떻게 실행되는지는 내부에서 결정
가장 일반적인 스크립트 코드
CSS, HTML, SQL, JSON, Template
컴퓨터가 이해하기 좋은 코드
기획문서에 가까운 코드
확실히 선언적 프로그래밍이 명령형 프로그래밍에 비해 가독성, 재사용성, 독립성, 유지보수성면에서 좋다.
cf) Framework vs jQuery
2. 변경사항의 전파(Pull -> Push)
Pull에서의 Push로의 전환
Pull
Push
관련 데이터가 필요한 시점에 데이터를 요청하는 방식
값이 변경될때마다 변경된 값을 전파해서 사용
레거시 데이터가 있거나 중복 요청이 있을 수 있음
언제나 변경된 최신의 데이터를 가지고 있음
웹을 기준으로 생각해보면 기존에는 DOM 조작을 통해 화면을 구현하는 것이 중심이기 때문에 Render를 해야 하는 시점에 필요한 데이터를 모두 불러와서 화면을 출력하는 Pull 관점에서 UI 개발을 했다. 새로운 반응형 프로그래밍의 패러다임에서는 미리 선언이 되어 있는 구조에서 값이 변화할 때마다 템플릿으로 데이터 전달하는 Push의 관점으로 설계가 되도록 변화했다.
3. 반응형 프로그래밍 패러다임으로의 전환
웹 프로그래밍은 데이터를 가져와서 화면을 만드는 방향에서 무엇을 할지 선언을 하고 변경된 데이터를 감지하고 전파하는 방향으로 패러다임이 변해왔다. 초기에는 반응형 프로그래밍 패러다임이 뷰에 집중되었다면 이후에는 뷰를 넘어 비즈니스 로직을 포함한 모든 스크립트에서 사용할 수 있도록 개념이 확장된다. 상태 관리라고 하는 것들도 데이터의 변경을 감지하고 변경을 전파하고 선언적으로 값을 만들어내는 반응형 프로그래밍 패러다임에 속하게 된다.
비동기 프로그래밍
프론트엔드 프로그래밍에서 반응형 프로그래밍이 중요한 이유는 비동기 프로그래밍을 잘하기 위함이다.
거의 대부분의 프론트엔드 로직이 비동기로 동작한다고 해도 과언이 아니다. 유저의 인터랙션, 서버의 응답 모두 언제 어떻게 동작할지 예측할 수 없다.
비동기 프로그래밍이 어려운 이유
작성한 코드 순서대로 동작하지 않음
언제 실행이 될지 예측하기 어려움(작업이 언제 끝날지 모름)
호출한 순서대로 동작한다는 보장이 없음
호출 당시의 값과 실제 실행되었을 때의 값이 그대로일 것이라는 보장이 없음
JS의 Callback
적어도 비동기를 작성한 순서대로 동작할 수 있도록 하기 위해 Callback을 많이 사용하게 되었다. 하지만 이는 Callback Hell이라고 불리우는 문제를 발생시켰다.
위의 문제 의식에서 비동기 로직을 동기 프로그래밍처럼 동작할 수 있도록 해결책이 출발하였다.
다시 반응형 프로그래밍
DOM에서 쓰는 이벤트 리스너(이게 무엇인지는 다른 Post에서 살펴보기로 함)
모든 스크립트에서 Event Listener의 관점으로 프로그래밍을 하는 것
제어의 역전(Inversion of Control)
[ Foo ] -> [ Bar ]
위와 같이 2개의 모듈 존재
네트워크 요청을 받았을 때 Bar 모듈의 값을 증가하는 로직
// Foo.js
import Bar
function onNetworkRequest() {
// do something
Bar.incrementCounter(value)
}
상태 변화는 Bar에서 일어나지만 동작은 Foo가 하도록 하고 있음
Bar는 Foo의 존재를 알 수 없음
Bar는 Passive(수동적)인 상태가 되고, Foo 모듈과는 강한 결합도를 가지게 된다. 이는 자체 상태 관리를 못하게 되고, 수정이 필요한 모든 로직을 Foo에 공개하는 형식으로 유도한다.
위와 같은 문제를 해결하기 위해서 화살표의 방향을 반전시키지는 안되 화살표의 소유권을 반전시키는 식으로 해결할 수 있다.
모듈과 모듈 간의 결합 시에 참조의 주체를 바꾸어 사용하는 방법을 제어의 역전이라고 부른다.
이벤트를 하나의 값으로 생각하고 이를 Array의 Method를 다루듯이 작성하면 직관적이고 간결한 프로그래밍을 할 수 있음
스트림을 여러 개로 연결한다면?
수많은 비동기 작업이 수행
각각의 작업은 하나의 노드로 바라볼 수 있음
전체 프로그램의 복잡도를 고려하지 않고 노드를 하나의 스트림으로 정의하고 선언적으로 개발을 할 수 있음
독립적인 노드만 생각하고 input -> output의 경로만 잘 맞추면 데이터 전파로 인해 알아서 반응하는 형태의 프로그램이 만들어짐
Data flow 프로그래밍
프로그램을 데이터가 흐르는 방향 그래프로 간주하여 설계하고 각 간선간의 내용을 구현하는 형태의 프로그래밍 패러다임
각자의 변경사항을 전파하도록 설계하면 알아서 복잡한 데이터의 흐름이 만들어지지만 내부를 들여다보면 단순한 형태의 프로그래밍을 할 수 있게 함
이벤트를 값으로 다룬다는 관점이 매우 중요
함수형 프로그래밍
반응형 프로그래밍에서는 이러한 Data-flow를 함수형 프로그래밍을 통해서 구현하고 있음
함수형 프로그래밍이란 원본 값을 함수를 통해서 전달을 하고 새로운 값을 만들어내는 조합이 다시 하나의 함수가 되는 형태의 구조
이벤트를 통해 데이터가 전달되는 흐름을 중첩된 파이프라인을 통해서 전달을 할 수 있도록 도와줌
ReactiveX(Rx)
Operator
스트림 프로그래밍에서 반복적으로 발생하는 간선들을 API로 제공
e.g. Map, Filter, Take, Concat, Skip, First, Last, Count
반응형 프로그래밍이란, 데이터의 흐름과 변경사항의 전파에 중점을 둔 선언적 프로그래밍 패러다임이다.
= 모든 것을 스트림으로 간주하고 선언적으로 개발하는 것이다.
= e.g. Array, Iterator, Promise, Callback, Event ... => 스트림이라고 하는 하나의 관점으로 간주
결론
반응형 프로그래밍은 구현체나 라이브러리가 아니라 비동기를 잘 다루기 위한 프로그래밍 관점 및 체계이다.
키워드
패러다임
관점
,방법론
이다.패러다임을 알고 있어야 하는 이유
반응형 프로그래밍 패러다임
스프레드 시트
패러다임의 전환
1. 선언적 프로그래밍
명령형 vs 선언적
2. 변경사항의 전파(Pull -> Push)
Pull에서의 Push로의 전환
웹을 기준으로 생각해보면 기존에는 DOM 조작을 통해 화면을 구현하는 것이 중심이기 때문에 Render를 해야 하는 시점에 필요한 데이터를 모두 불러와서 화면을 출력하는 Pull 관점에서 UI 개발을 했다. 새로운 반응형 프로그래밍의 패러다임에서는 미리 선언이 되어 있는 구조에서 값이 변화할 때마다 템플릿으로 데이터 전달하는 Push의 관점으로 설계가 되도록 변화했다.
3. 반응형 프로그래밍 패러다임으로의 전환
웹 프로그래밍은 데이터를 가져와서 화면을 만드는 방향에서 무엇을 할지 선언을 하고 변경된 데이터를 감지하고 전파하는 방향으로 패러다임이 변해왔다. 초기에는 반응형 프로그래밍 패러다임이 뷰에 집중되었다면 이후에는 뷰를 넘어 비즈니스 로직을 포함한 모든 스크립트에서 사용할 수 있도록 개념이 확장된다. 상태 관리라고 하는 것들도 데이터의 변경을 감지하고 변경을 전파하고 선언적으로 값을 만들어내는 반응형 프로그래밍 패러다임에 속하게 된다.
비동기 프로그래밍
비동기 프로그래밍이 어려운 이유
JS의 Callback
다시 반응형 프로그래밍
제어의 역전(Inversion of Control)
위와 같은 문제를 해결하기 위해서 화살표의 방향을 반전시키지는 안되 화살표의 소유권을 반전시키는 식으로 해결할 수 있다.
모듈과 모듈 간의 결합 시에 참조의 주체를 바꾸어 사용하는 방법을 제어의 역전이라고 부른다.
제어의 역전 방식은 DOM의 Event나 Observer 패턴, Pub/Sub 패턴과 같이 오래전부터 사용해오던 방식이다. 미들웨어나 플러그인과 같은 방식에서도 이미 자주 쓰이던 방식이다. 여러 개의 모듈 간의 결합이 많아질수록 더 유리하다.
ReactiveX(Rx)
정리
변경사항의 전파 + 데이터 흐름 = Event
이다.선언적
Stream(스트림)
스트림을 여러 개로 연결한다면?
Data flow 프로그래밍
함수형 프로그래밍
ReactiveX(Rx)
Operator
결론
반응형 프로그래밍은 구현체나 라이브러리가 아니라 비동기를 잘 다루기 위한 프로그래밍 관점 및 체계이다.
Links: 프로그래밍 패러다임과 반응형 프로그래밍 그리고 Rx, 테오의 프론트엔드