Closed kth990303 closed 1 year ago
책이 아무래도 번역본이라 매끄럽지 않아 이해하기가 쉽지 않군요..ㅜㅜ 정확하진 않지만 제가 이해한 내용을 한번 정리해 봅니다.
선언적이지 않은 설계
라면 패지키/모듈을 분리하더라도 가까운 경계 내에서 분리하고,
선언적 설계
라면 아예 별개의 패키지/모듈로 분리하는게 가능하다 라는 내용으로 이해했습니다.
제가 생각하는 선언적이지 않은 코드
와 선언적인 코드
를 예시로 들어보면,
선언적이지 않은 코드
validateDay(day) // 날짜를 검증하는 로직입니다.
위 코드도 검증 로직과 다른 로직을 분리하는 작업은 필요하겠지만, validateDay
만 보고는 어떤 로직인지 알 수 없고 실제 코드를 봐야 알 수 있겠죠. (즉, 패키지/모듈 간의 의존성이 존재합니다.)
선언적인 코드
day
.filter(isBeforeToday)
.filter(isNotMinus)
위 코드는 day 를 각 람다 함수로 필터링하는 로직입니다. isBeforeToday
나 isNotMinus
같은 함수는 아예 별개의 패키지/모듈에 독립적으로 존재할 수 잇겠죠.(의존성이 존재하지 않습니다. 각 함수들의 연산이 명확하고, 일반적이니..)
요약하자면, 의존성을 분리한다 vs 의존성을 완전히 끊어버린다 의 차이라고 생각하였습니다.
10 장 p.283 의 독립형 클래스 에서 각 클래스의 의존성을 최대한 없애는 걸 설명하는데(극단적이라면 zero) 이와 비슷한 내용인 듯 합니다!
선언적 코드란 무엇일까?
어떻게 보면 검증을 의미한다고 명확히 해석이 되는 validateDay(day)
가 좀 더 선언적인 코드가 될 수 있지 않을까 vs 무엇을 검증하는지 명확하게 드러내주는day.filter(isBeforeToday)...
와 같이 그 코드만 보고 내용을 바로 이해할 수 있는 코드가 좀 더 선언적인 코드가 될 수 있지 않을까
질문
p.119 에 아래와 같은 문구가 나옵니다.
저는 해당 문구를
높은 응집도/낮은 결합도
를 기준으로 각 도메인을 모듈화(패키지화)하여 책임 및 관심사를 분리하여, 특정 도메인 개발자가 자신의 도메인에만 신경쓸 수 있도록 해야 한다고 이해했습니다. 패키지화(모듈화)의 장점에 대해 얘기한 문구라고 생각한 것이죠.의문이 든 부분
그런데 아래 문구를 보고 의문이 들었습니다. 아니, 사실 이해가 아예 안된다고 하는 게 맞겠네요.
선언적 설계는 저번 시간에 얘기를 나눴듯이, 세부 로직은 캡슐화하고 결과를 반환하는 형태라고 (대략적으로) 알고 있습니다. 따라서 개발자들은 코드를 읽을 필요가 없다는 것은 이해가 됩니다.
그런데 이해가 되지 않는 부분은
한 가지 예외적인 경우
문구입니다. 패키지화(모듈화) 역시 타 모듈에 대한 코드를 읽지 않기 위해 별도의 모듈로 분리하는 것인데 왜선언적 설계는 예외적인 경우
라고 말하는 것일까? 하는 생각이 들었습니다.선언적 설계에 대해 잘 몰라서 그런 것일수도 있다고 생각합니다. 왜 책에서는 이렇게 말한건지 잘 모르겠습니다..
어렵네요 흑흑연관 챕터
24