composable/

[utterances-bot]

합성으로 연결되는 함수형과 객체지향

객체지향과 함수형을 관통하는 핵심 아이디어는 뭘까요? 저는 바로 합성하기 쉬운Composable 프로그램을 만드는 거라 생각합니다

https://twinstae.github.io/composable/

[tothefullest08]

안녕하세요!
평소에 관심있던 주제에 대해서 심도 깊은 내용으로 포스팅해주셔서 너무나 재밌게 읽었습니다.
한가지 궁금한점이 있어서 코멘트 남기게 되었어요.

함수형에서 다형성을 지원하는 방법중 하나로, 완전패턴매칭과 프로토콜을 말씀주셨는데요, 완전 패턴매칭은 포스팅에서도 잘 말씀주셨던 것 처럼, 결합도가 높고 새로운 요구사항이 생길때마다 코드 수정을 해줘야하는 단점이 있다고 저도 생각해요. 이러한 부분을 개선하여, 클로저나 엘릭서같은 함수형 언어에서 프로토콜이라는 기능이 있다고 말씀주셨는데, 프로토콜도 새로운 요구사항이 생겼을때 코드를 수정하는건 똑같지 않은가요?

함수형 언어의 프로토콜 기능이 완전패턴매칭의 단점을 어떻게 보완하고 있는지 궁금합니다!

[twinstae]

@tothefullest08 안녕하세요~ 좋은 질문입니다.

중요한 건 인터페이스를 정의할 때 구현까지 정해야한다는 것입니다.

첫 번째 예시로 외부 라이브러리나 프레임워크의 함수가 내부적으로 패턴매칭을 쓴다고 하면, 그 라이브러리 쪽에서 패턴매칭에 경우의 수를 하나 추가해주기 전까지는 새 타입에 대한 처리를 추가할 수 없을 겁니다. 반면에 프로토콜이나 러스트 식 trait나 고랭 식 receiver는 우리가 소유하고 있지 않은 함수라도 동일한 인터페이스로 새로운 구현체를 추가할 수 있습니다. 이러한 특성은 우리가 소유한 코드가 외부 프레임워크나 라이브러리와 함께 유연하게 협력할 수 있게 도와줍니다.

두 번째로는 응집성인데요. 경우의 수가 얼마 없을 때에는 모든 경우의 수가 하나의 함수에 몰려 있는 패턴매칭이 그럴듯해보일지 모릅니다. (option처럼 2가지 뿐이라거나) 하지만 경우의 수가 계속 늘어날 수 있다고 하면... 새로운 도메인이나 타입을 추가할 때마따, 이 타입을 사용하는 모든 패턴매칭 함수들을 찾아가서 추가해줘야 할 겁니다. 반면에 프로토콜 등등은 내가 만든 새 타입이나 로직을 기존의 함수의 내부를 건드리지 않고 유연하게 변경할 수 있습니다.

그 외에도 여러 차이들이 있지만. 슬프게도 주류 언어들에는 패턴매칭도 프로토콜도 없는 경우가 많아서. (요즘 패턴매칭은 좀 들어오는 것도 같습니다만?) 패턴매칭도 잘 쓸 수 있을 때에는 여러모로 유용한데 늘 아쉽게 생각하고 있습니다. 제가 일하는 프론트엔드 같은 동네에서는, 다형성보다는 if문을 점철해서 처리하는 경우가 많기도 합니다...

[tothefullest08]

@twinstae 답변주신 내용이 제가 추측했던 생각했던 부분과 비슷해서, 덕분에 궁금증이 잘 해소 되었습니다.
빠른 답변 감사합니다!

우연히 함수형 개발자 컨퍼런스에서 블로그를 찾게되어 좋은 내용 잘 읽었습니다!
컨퍼런스도 가보고싶은데 이미 표가 매진되어서 아쉽네요 ㅠ

[roeniss]

글이 너무 재밌습니다. 엉클밥에 대한 생각을 얘기하는 글도 기대해보겠습니다 ㅎㅎ

[twinstae]

글이 너무 재밌습니다. 엉클밥에 대한 생각을 얘기하는 글도 기대해보겠습니다 ㅎㅎ

@roeniss

제가 함수형에 입문한 계기가 밥 아저씨였어요. 클린 소프트웨어의 디자인 패턴을 보다가. 아니 이렇게 장황한 게 클린이란 말인가? 하고 당시에 주워들은 일급함수로 리팩토링하니까 너무 깔끔하더라고요. 그래서 함수형 세력에 관심이 생겼었죠.

엉클 밥은 정치적으로나 코딩적으로 좋아하지 않지만 테스트나 동적 언어, 클로저 같은 일부 취향에서는 겹치기도 하는 것 같습니다 ^^;;; 저는 앨런 케이와 데이브 토머스, 마틴 파울러가 좋아요.