2021.06.04~05 기록장

To Do

• 책 읽기
• 회고 작성
• 목 test 해보기
• git action 공부
• pr 읽기

Done

• 리뷰 반영
• 목 test 해보기
• git action 공부
• 책 읽기

Weekly goal

• 책 읽기
• 블로그 읽기

Feeling

오늘은 디온이 리뷰 달아주신 거 반영을 했다. 꽤 많이 달려서 거의 하루 종일 했다.

 

git action을 봤는데 다음 미션에 적용해 봐야겠다. 특정 브랜치가 push가 되면 s3로 올리게 하고

ec2에서는 1분 간격으로 s3를 확인하면서 있으면 가지고 오는 자동 배포를 해봐야지.

 

책은 object 6 챕터를 읽었다.

읽으면서 이번 미션에서 생각했던 점과 결론을 쓰자면 다음과 같다.

 

195p. 함께 모으기 (묻지 말고 시켜라)

예제의 내용을 보면 객체에게 시키는 작업을 계속해서 타고 타고 한다.

이것과 이번 미션에서 비슷한 부분은 예약을 만드는 로직이다.

처음에는 예약 검증을 하나하나 따로 했다. 그리고 따로따로 외부에 노출을 했다.

 

그러다 객체에게 물어보고 싶은 것은 결국 예약이 가능한지 여부이기에 하나의 메서드만 노출하는 식으로 변경을 했다.

이렇게 되니 내부적으로 타고 타고 들어가 검증을 하는 로직 구현이 되었다.

 

201p. 원칙의 함정

책임에 관한 부분이다. 나는 항상 묻지 말고 시켜라 라는 말을 지키려 했다.

하지만 이런 형태도 상황을 판단하면서 해야 한다는 것이다.

할인이 가능한지 여부는 PeriodCondition에 있다. 하지만 정보 전문가의 관점에서 봤을 때는 많은 정보가 Screening에 있다.

그렇다고 Screening에 할인 여부를 물어보는 게 맞는 형태인가?

내가 아무 생각 없이 짰다면 get을 줄이려고,. 를 줄이려고 Screening에 물어봤을 것 같다.

하지만 책에서는 getter를 쓰더라도 책임에 따라 코드를 배치하라는 것이다.

정보는 Screening이 가지고 있지만 그의 책임은 아니다.

 

203p. 명령-쿼리 분리 원칙

메서드를 하다 보면 하나의 메서드에서 수정과 정보 반환을 동시에 하는 경우가 있다.

하지만 이 원칙에 따르면 그러지 말고 수정 따로 정보 반환 따로 하라는 것이다.

 

객체의 상태를 변경하는 명령은 반환 값을 가질 수 없다.

객체의 정보를 반환하는 쿼리는 상태를 변경할 수 없다.

 

위의 두 가지 원칙을 지키게 된다면 반환 값만 보고도 그 메서드의 행동을 유추할 수 있다.

또한 반환 값을 받으려 했다가 상태가 변경되는 사이드 이펙트를 예방할 수 있다.

 

190, 196. 메서드 이름 붙이기

묻고 답하기를 하면서 객체를 타고 타고 들어가다 보면 메서드의 이름 짓기가 참 어렵다는 생각이 든다.

본인 생각에는 다 똑같은 일을 하는 것으로 보이는 데..

그래서 저자가 알려주는 방식은 메시지를 전송해서 얻고 싶었던 결과가 무엇인지 생각하라는 것이다.

 

 

극장(클라이언트)이 티켓 판매원(서버)에게 원했던 것은 고객에게 티켓을 파는 sellTo가 되고,

티켓 판매원(클라이언트)은 고객(서버)에게 원했던 것은 setTiket이 아니라 티켓 판매인 buy가 된다.

이런 식으로 무엇을 원하는지에 따라 메서드 이름을 지으면 될 것 같다.