함수형 프로그래밍

1. Functional Programming
& Reactive
Jesse Lee (이동현)
jesse.lee@kakaocorp.com
wracker12@hanmail.net

2. Functional Language
❖ Function is first class citizen in Functional Language
World
❖ 변수
❖ 인자
❖ 리턴
❖ ‘그렇다면 JS도 함수형 언어겠네!’ 라고 생각한적도 있었다.
❖ 다른 특성들도 알아보자!

3. Function
❖ y = f(x)
❖ 인자 x, 결과 y
❖ 2 = f(1)
❖ 4 = f(2)
❖ 6 = f(3)
❖ y = x * 2
❖ 우리가 이미 알고 있는 것들

4. Functional Programming
❖ 이것 또한 이미 알고 있는 것들
❖ 들어본적 있거나 이미 하고 있는 것들
❖ 그렇지만 엄격히 지키지 않는 것들

5. Function
❖ y = f(x)
❖ 3 = f(1)
❖ 5 = f(2)
❖ 7 = f(3)
❖ 실제 함수
❖ y = ax + b
❖ a = 2, b = 1

6. Function
❖ 그런데 이 함수(y = 2x + 1)의 결과가 갑자기
❖ 6 = f(2)
❖ 8 = f(3)
❖ 또는
❖ f(2) 호출을 해도 답이 없거나…
❖ “3” = f(1)
❖ “삼” = f(1)
❖ null = f(-1)
❖ 이라고 나온다면...??

7. Side Effect

8. Side Effect
❖ 값이 변하면(mutable) 그 값을 참조하는 모든 곳에서 변
화가 일어난다.
❖ 항상 모든 곳, 모든 상황에서 예측이 가능하다면 문제가
없겠지만...
❖ 직접 만든 만든 프로그램, 가져다 사용하는 라이브러리
모든 곳에서 부작용은 발생 할 수 있다.
❖ 함수형 프로그래밍을 하지 않는다면...

9. Side Effect
❖ 부작용을 만드는 상황
❖ Mutable 한 변수
❖ Mutable 한 지역변수, 전역변수 등...
❖ Void 함수

10. How to avoid side effect
❖ Immutable: val, let, final, const 등…
❖ 한번 값을 할당하면, 값이 변하지 않게 사용한다.
❖ mutable을 사용하지 않으려면, copy 또는 new가 필
요하다.
❖ Stateless
❖ 상태(Mutable)를 가지지 않아야 한다.

11. How to avoid side effect
❖ Return
❖ void함수는 black box 이다.
❖ 우리가 만든 함수뿐만 아니라, 라이브러리의 함수가
void일 경우 까보지 않으면 블랙박스나 마찮가지다.
❖ 항상 그렇지는 않지만, 부작용을 만들어 낼수 있는
중요한 포인트이다.
❖ return이 있고, 예측가능해야 Test를 적용 할 수 있다.

12. Type Safe
❖ 함수(y = 2x + 1)의 결과가 갑자기
❖ 6 = f(2)
❖ 8 = f(3)
❖ 또는
❖ f(2) 호출을 해도 답이 없거나… (Side Effect)
❖ “3”: String = f(1)
❖ “삼”: String = f(1)
❖ null: Null = f(-1)

13. Type Safe
❖ 타입 안정성을 헤치는 것들
❖ Any
❖ Object
❖ null
❖ nil
❖ 강제 캐스트
❖ Type Safe하게 만들려면 이런 것들을 안사용하면 됨
❖ 그렇지만 이것 또한 쉽지 않은 것처럼 보임
❖ null, 강제 캐스트만 사용하지 않아도 훨씬 타입안심(?)하고 사용할 수 있다.

14. Type Safe
❖ 함수형 프로그래밍을 하지 않을때 종종 사용하는 패턴
❖ return null
❖ Person p = null
❖ var i = null
❖ 사실 이 모든 문제들은 mutable을 허용 할 경우에 발생한다.
❖ 내가 기대하는 타입은 null이 아닌데 null을 받는 경우가 있다면
❖ If (i == null)
❖ null 체크를 하면 되지...

15. Type Safe
❖ Json Serialize, Deserialize
❖ val data = { “name”: “Jesse”, “age”: null }
❖ class Person(name: String, age: Int)
❖ val person = Json.parse(data)
❖ deserialize가 된다면, type safe 하다고 할 수 없다.
❖ 왜냐면 null은 Int가 아니니깐... Any, Object, 다른 모든 경우에
도 Type은 일관성이 있어야 한다.
❖ 그래야 예측 가능하니깐...

16. Type Safe
❖ Type Safe를 보장 할 수 없다면
❖ null체크를 열심히 하거나
❖ null을 return할수도 있는지 함수 정의를 찾아보거나
❖ 사용하는 라이브러리 소스를 확인해야하는데
❖ Type Safe하다면 얼마나 귀찮고, 불필요한 과정인가
❖ String returnStringFunction()
❖ 항상! String만 리턴 할 것이다. (믿고 쓰는 함수)

17. Type Safe
❖ Option, Optional
❖ Nullable - null이 될수도 있는 것과, null이 될 수 없는 것
은 확실하게 분리해서 사용할 것
❖ (O) String returnString() = { return “” }
❖ (X) String returnString() = { return null }
❖ (O) Optional<String> maybeString()
❖ Optional을 리턴한다고 해서 null을 리턴해서는 안된다

18. Type Safe
❖ null을 리턴 할 수도 있는 라이브러리를 사용할때

19. Type Safe
❖ null을 리턴 할 수도 있는 라이브러리를 사용할때
❖ 라이브러리 Wrapper 를 만들어 캡슐화 한다.
❖ 다른 곳에서 해당 라이브러리를 직접 사용하지 않아야
하며, Wrapper를 이용하여 접근한다.
❖ null을 리턴 할 수 있는 함수는 Optional로 감싸서 리턴
한다.

20. Type Safe

21. Functional Language
❖ 함수형 언어는 앞서 이야기 한 것들을 문법적인 제약(?)을
두고 있다.
❖ ex) 노윤허 - mutable 변수
❖ ex) 노윤허 - type이 맞지 않는 return
❖ ex) scala의 경우 강제로 제약을 하고 있지는 않지만,
Anti-Pattern이다 - 그래서 완전한 함수형 언어가 아니라
고 하기도...

22. Functional Language
❖ 비함수형 언어를 사용하던 사람들에게 이러한 제약들은
언어를 배우는데 허들이 될 수 있다고 생각한다.
❖ 함수형 언어의 앞서 설명한 개념들은 기존의 언어, 또는
비교적 근래에 생겨난 모던 랭귀지에 많이 차용되고 있
다.

23. Functional Language
❖ 함수형 언어하면 맨날 나오는거...

24. Monad
❖ 이게 뭘까요
❖ 저도 잘...
❖ 몰라도 함수형 언어로 개발하는데 아무 문제 없습니다.
❖ 알면 더 좋을 것 같기도 하고...

25. Monad Laws
❖ 모나드는 어떤 값을 갑싼 타입이다.
❖ Wrap<T>
❖ 모나드는 모나드를 만들 수 있는 생성자 또는 함수가 있어야 한다.
❖ unit
❖ Scala에서 대표적인 모나드인 Option을 이용해서 확인해보자
❖ flatMap의 역할에 주목하자
❖ 모나드<?> = 모나드<T>.flatMap(x: T => 모나드<?>)
❖ flatMap의 인자는 모나드를 리턴하는 함수
❖ flatMap의 리턴값은 모나드이다.

26. Monad Laws
❖ 우단위원의 법칙 (Right Unit)
❖ m flatMap unit == m

27. Monad Laws
❖ 좌단위원의 법칙 (Left Unit)
❖ unit(x) flatMap f == f(x)

28. Monad Laws
❖ 결합법칙 (Associativity)
❖ m flatMap f flatMap g == m flatMap(x => f(x) flatMap g)

29. Monad Laws
❖ 결합법칙 (Associativity)
❖ m flatMap f flatMap g == m flatMap(x => f(x) flatMap g)

30. Monad
❖ 이런 녀석을 왜 사용하는 걸까요?
❖ 사용하면 어떤 이점이 있을까요?
❖ 모나드는 이런 법칙들과 함께 핵심이 되는 비즈니스를 감추고 있
습니다.
❖ 감추고 있다고 할수도 있지만
❖ 굳이 몰라도 되는...
❖ 귀찮게 반복하는 것들...
❖ 형식적으로 반복하는 것들...

31. Monad

32. Monad
❖ Try[T]
❖ Exception을 핸들링 하지 않아도 되는...
❖ 핸들링 하고 싶으면 할 수 있는 방법도 제공
❖ Future[T]
❖ 보통 Callback은 T => Unit의 형태를 가진다.
❖ Lazy하게 처리, 관심이 있는 값을 인자로 받는다.
❖ Callback을 핸들링 할 수 있는 다양한 방법 제공
❖ 덕분에 callback hell 패턴을 피할 수 있다!
❖ 결합의 법칙을 만족하지 않아서 모나드가 아닌 모나딕이라고 하는데...

33. Reactive
❖ 리액티브 프로그래밍
❖ 리액티브 시스템
❖ 리액티브 마이크로 서비스
❖ 주제가 너무 많으니 다음에 더 준비해서 하겠습니다 ^^