Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[question] 클라이언트는 메시지의 인자와 반환 타입을 어떻게 결정해야 하나요 #25

Open
binchoo opened this issue Apr 24, 2022 · 0 comments
Assignees
Labels
question 이해되지 않는 부분이나 궁금한 부분을 스터디에 질문

Comments

@binchoo
Copy link
Member

binchoo commented Apr 24, 2022

클라이언트는 메시지의 인자와 반환 타입을 어떻게 결정해야 하나요

챕터6에서는 인터페이스의 품질을 높이기 위한 가이드라인을 살펴 보았습니다.

책임 주도 설계를 적용하여 인터페이스를 클라이언트가 결정하고
그 구현은 감추어 버리는 것이 큰 맥락이었습니다.

메시지 전송 = {메시지 수신자, 오퍼레이션명, 인자}
시그니처 = {오퍼레이션명, 인자, 반환 타입}을 최적화하는 4가지 가이드를 받았습니다.

  • 디미터 법칙 & 묻지 말고 시켜라: 메시지 수신자를 잘 결정하는 법
  • 의도를 드러내라: 오퍼레이션명을 잘 결정하는 법
  • 명령-쿼리 분리: 반환타입 유무의 관습을 따라라

아직 부족한 것이 있습니다.

  • 메시지 전송의 인자는 어떻게 해야하는가?

더불어 모든 오퍼레이션의 시그니처는 반환 타입이 있어요.

  • 그럼 반환 타입은 어떻게 해야하는가?
  • 명령-쿼리 분리 지침은 반환의 유/무를 토대로 상태 변화의 무/유 파악하라는 내용으로, 반환의 타입에 대한 내용이 아니었습니다.

그러니 인자반환 타입에 대해 보충이 필요해 보입니다.

인자 타입과 반환 타입에 대한 의존

클라이언트는 협력 객체의 타입 뿐만 아니라

메시지에 담아야 할 인자 타입과 반환 타입에도 의존합니다.

TaskSpec taskSpec = ...;
List<Task> tasks = this.taskGenerator.generateTasks(taskSpec);

(반환을 명시적으로 담아낼 변수를 선언하지 않는다면, 반환 타입 소스코드 의존을 없앨 수 있긴 합니다.)

TaskSpec taskSpec = ...;
this.taskGenerator.generateTasks(taskSpec).forEach(System.out::println);

어찌되었든 클라이언트의 소스코드가 인자 타입과 반환 타입에도 의존하는 것이 사실입니다.
그 의존성을 관리하는 것 역시 중대 사안이라 생각하는데요.

여러분은 어떻게 제어하고 계신가요?

계층 아키텍처에서 어떻게 하고 계신가요?

layered

  • 콘트롤러 -> 서비스
  • 서비스 -> 레포지토리

포트와 어댑터 아키텍처에서 어떻게 하고 계신가요?

IMG_0137

  • UI 어댑터 -> 드라이빙 포트
  • 서비스 -> 드라이븐 포트
  • 인프라 어댑터 -> 인프라 특화 레이어

연관 챕터

#22

@caffeine-library/readers-objects

@binchoo binchoo added the question 이해되지 않는 부분이나 궁금한 부분을 스터디에 질문 label Apr 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question 이해되지 않는 부분이나 궁금한 부분을 스터디에 질문
Projects
None yet
Development

No branches or pull requests

6 participants