Facts & Findings
FP in scala 스터디
class 와 case class 에 대해서 배웠다. 이전까지는 별 생각없이 하다가 new 연산자를 붙이지 않은 객체 생성이 터지는 걸 보고(이래서 TDD 가 좋다) 함께 원인을 탐구하면서 알게 되었다.
전날에 도메인 주도 설계에서 VO 와 Entity 객체 패턴을 읽어서, 조금 더 관심있게 읽어볼 수 있었다. case class 는 객체를 불변으로 보고, 패턴 매칭과 동등성 비교등을 지원한다. 일반적인 클래스를 Entity 패턴을 구현하는데 사용하고, case class 를 VO 패턴을 구현하는데 사용하는 것 같다. 두 객체를 비교할때, 기본적으로 객체의 데이터 구조(패턴 매칭)와 값으로 비교하게 된다. 객체를 생성하는 생성자도 달라서, case class 의 경우에는 동반 객체의 apply 메서드를 통해서 생성해준다.
DDD 에서는 이 뿐만 아니라, DB 에서 데이터 분산으로 조회속도 향상을 노릴때, VO 패턴을 활용하는 전략에 대해서 말해주고 있는데, 이 부분도 좀 찾아봐야겠다는 생각이 들었다.
오늘의 주된 내용은 상태있는 API 를 순수하게 만드는 것이었다. 오늘은 RANDOM API 를 다루었다. 이런 API 들은 매번 요청할때마다 응답이 달라지게 하기 위해서, 내부 상태를 요청이 들어올때마다 변경하는 패턴을 가지고 있다. 다만 이렇게 드러나지 않은 상태 변경은 참조투명성을 해치게 된다. 따라서, 함수형 프로그래밍에서는 상태 변경을 명시적으로 드러내는 전략을 취한다.
이 경우에도 관심사의 분리가 활용된다. 상태변경을 명시적으로 해준다라는 것을 새로운 상태의 계산이라는 책임과 새로운 상태를 외부에 알려주는 책임이라는 두가지의 책임으로 나누어 생각한다.
다만, 이렇게 상태 변경을 명시적으로 드러내게 되면, 인터페이스가 안좋아진다. 책에서는 몇가지의 예시를 통해 어떤 불편한점들이 발생하고, 이를 어떻게 해결하면 좋을지를 말해주고 있다. 다음주에는 여기부터 공부하면 될것 같다!
- 스칼라 case class: https://docs.scala-lang.org/tour/case-classes.html
알고리즘 문제 풀이 스터디
MADMAX 팀원분들과 스터디를 했다. 자주 등장하는 BFS, DFS 에 대해서 다시 한번 짚고 넘어가는 시간을 가졌다. 좀 헷갈리는 부분이 있어서 계속해서 설명을 하면서, 논리적으로 부족한 부분을 채워가려고 애썼다.
몇번의 이야기를 거치고 구현도 몇번 해보니, DFS 와 BFS 에 대해서 조금 더 단순하게 이해할 수 있게된것 같다. 핵심은 다음에 탐색할 노드를 어떤 식으로 선택하는가일 뿐이다.
Feelings
무언가 해볼 수 있는 상태가 매우 감사하고 좋게 느껴진다. 할수 있는 부분을 찾아내서 조금씩 하다보면 어느새 풍경이 바뀌는 것도 신기하게 느껴진다. 단지 바라는 것은, 모든일을 대하는 나의 태도가 조금 더 의연했으면 좋겠다는 것이다.
Affirmation
나는 다짐보다 구체적인 행동을 더 신뢰하는 사람이다.
