(defrecord Assistant [name id])
(updatePersonalInfo )
Manager:
(defrecord Manager [name id employees])
(raise )
(extend-type Assistant Employee
(roles [this] "assistant"))
(extend-type Manager Employee
(roles [this] (str "manager of " (count employees))))
85
The Expression Problem
86
The Expression Problem
Add a new
data type
Add a new
operation
Without changing:
- Existing data types
- Existing operations
87
The Expression Problem
Add Employee
Add raise()
Without changing:
- Assistant
스티븐 블랙히스, 앤서니 존스 지음 | 오현석 옮김 | 한빛미디어
함수형 반응형 프로그래밍에 관한 최초의 종합 안내서
프로그램은 ‘어떻게’가 아니라 ‘무엇’을 기술하는 선언적인 문서여야 한다는 주장을 받아들이는 사람이 점점 늘고 있다. 이런 흐름은 함수형 언어의 부흥으로 이어졌다. 함수형 언어로는 프로그램을 더 선언적인 방식으로 작성할 수 있고, 이를 이벤트 처리에 결합한 것이 함수형 반응형 프로그래밍(FRP)이다. 지난 수십 년 동안 이벤트 처리 인프라를 책임진 관찰자 패턴은, 한편으로는 버그의 온상이 되기도 했다. FRP는 관찰자 패턴의 잠재적 버그 원인을 근본적으로 차단하여 더 복잡한 시스템으로 쉽게 확장할 수 있도록 해준다.
이 책의 저자는 FRP 프레임워크인 소듐(Sodium)의 창시자로서, FRP의 기초부터 기존 프로젝트를 점진적으로 FRP 시스템으로 탈바꿈시키는 방법까지 친절히 안내한다.
(defrecord Assistant [name id])
(updatePersonalInfo )
Manager:
(defrecord Manager [name id employees])
(raise )
(extend-type Assistant Employee
(roles [this] "assistant"))
(extend-type Manager Employee
(roles [this] (str "manager of " (count employees))))
85
The Expression Problem
86
The Expression Problem
Add a new
data type
Add a new
operation
Without changing:
- Existing data types
- Existing operations
87
The Expression Problem
Add Employee
Add raise()
Without changing:
- Assistant
스티븐 블랙히스, 앤서니 존스 지음 | 오현석 옮김 | 한빛미디어
함수형 반응형 프로그래밍에 관한 최초의 종합 안내서
프로그램은 ‘어떻게’가 아니라 ‘무엇’을 기술하는 선언적인 문서여야 한다는 주장을 받아들이는 사람이 점점 늘고 있다. 이런 흐름은 함수형 언어의 부흥으로 이어졌다. 함수형 언어로는 프로그램을 더 선언적인 방식으로 작성할 수 있고, 이를 이벤트 처리에 결합한 것이 함수형 반응형 프로그래밍(FRP)이다. 지난 수십 년 동안 이벤트 처리 인프라를 책임진 관찰자 패턴은, 한편으로는 버그의 온상이 되기도 했다. FRP는 관찰자 패턴의 잠재적 버그 원인을 근본적으로 차단하여 더 복잡한 시스템으로 쉽게 확장할 수 있도록 해준다.
이 책의 저자는 FRP 프레임워크인 소듐(Sodium)의 창시자로서, FRP의 기초부터 기존 프로젝트를 점진적으로 FRP 시스템으로 탈바꿈시키는 방법까지 친절히 안내한다.
8. 함수형 언어는 구조물들 간에 커플링을 만들기보다는
큰 단위의 재사용 메커니즘을 추출 한다
카테고리 이론에 근거하여 재사용 메커니즘을 구축함으
로 상황에 따라 달리 지고 이동 가능한 코드를 만들 수
있다
#contextualized #portable
함수형 언어에서의 재사용
9. 카테고리 이론
수학의 여러 분야에서 공통적으로 발생하는 현상들을 추상화하여 정리하는 이론이다
각 분야를 정리해주는 언어는 제공해 줄 수 있어도
구체적인 문제를 해결하기 위해서는 다시 각 분야로 돌아가야 한다
http://www.aladin.co.kr/shop/wproduct.aspx?ItemId=76801071
18. Effective Java
규칙 16 : 계승하는 대신 구성하라
- 메서드 호출과 달리 계승은 캡슐화 원칙을 위반한다
- 하위 클래스가 정상 동작하기 위해서는 상위 클래스의 구현에 의존할 수 밖에 없다
- 상위 클래스가 수정됨에 따라 하위 클래스 코드는 수정된 적이 없어도 망가질 수 있다
다양한 패러다임을 가지고 있고 어떻게 사용하는지에 따라 다양한 방법으로 문제를 해결 할 수 있지만
문제에 가장 적합한 패러다임으로 접근하여 해결하는 것이 더 좋은 개발자로 진화하는 길이다.
진화하려면 이런걸 배워야 한다.. 그렇지 않으면 진화하지 못한다..
디자인 패턴은 개발 과정에서 발견된 설계의 노하우를 모아 놓은 집합체이며 재사용하기 좋은 형태로 규칙들을 묶어서 정리한 것이다.
함수형이라는 것 자체가 가변적인 것을 최소화하고 가변적인 부분은 외부로부터 함수의 형태로 입력 받아 처리함으로써 재사용의 단위가 oop에 비하면 굉장히 작아서
함수형에서는 디자인 패턴이 필요가 없다 생각 할 수 있지만 oop와는 다른 형태로 디자인 패턴이 나타난다
함수형 언어가 OOP보다 더 높은 위치의 추상화를 하고 있기 때문에 하나의 패턴 자체가 언어에 흡수되어 있는 형태가 가능하다
1장부터 나온 패러다임 전환/ 런타임에 제어를 언어에게 양도하기가 나온 것 처럼 접근 방식이 다르니 패턴에 대한 구현과, 다른 언어나 패러다임에 없는 기능으로 구현되는 것은 당연한 것 같다
객체지향 언어에서는 재사용의 대상이 되는 곳에 메서드들의 호출 관계가 포함되어 있기 때문에 특정 상황에서만 적용이 가능하다
객체지향 언어에서는 재사용 범위에 메서드 호출관계도 포함이 되어 있었지만 함수형 언어에서는 함수 자체가 1계층이기 때문에 상황에 따른 코드를 끼워 넣고 호출 할 수 있는 구조로 재사용을 지향한다. 여기서 카테고리 이론이라는게 나오는데,,,
자바에서 전략 패턴을 만들려면,, 일단 인터페이스 하나가 필요하고,, 이 인터페이스를 구현한 구현체들이 필요하다
딱 봐도 자바코드에 비하여 엄청 짧아졌다. 무슨 차이가 있는건가..
함수형에서는 인터페이스? 물론 스칼라에 trait 라는 인터페이스와 비슷한 녀석이 있지만 그런 보일러플레이트 코드들은 필요가 없다
입력과 출력형태만 보장되면 개발자 마음대로 만들어도 된다. 자바 처럼 새로운 전략을 추가하기 위해 인터페이스를 상속하여 구현체를 만드는 등의 번거로운 작업은 하지 않아도 된다
팩토리의 본질은 주어진 조건에 따라 다른 함수들을 리턴하는 함수를 만드는 것이다.
팩토리와 커링 둘 다 뭘 넣으면 뭐가 나오니,, 디자인 패턴 관점에서 이 두 개는 동일하다