2021.12.09 기록장

ToDo

• 책 읽기
•  

Done

• 책 읽기

Weekly goal

• 책 읽기
• 영어 레퍼런스 읽기
• 북마크 읽기, 정리
• 책 정리

 

리팩토링

325p. 메서드명 변경

상황)

db에서 값을 가지고 올 때 메서드 명을 select, find~,get~ 등등으로 통일이 되지 않는 문제가 있었다.

 

그래서 모여서 작명 방법을 정하기로 했다. 우리끼리 정해도 되지만 이미 만들어져 있는 jpa를 참조하기로 했다.

메서드 작명 방식을 따라 하는 것이다.

 

이를 통해 통일된 메서드명을, 의미를 알 수 있는 이름을 지을 수 있었다.

 

https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#:~:text=Table%203.%20 Supported%20 keywords%20 inside%20 method%20 names

Spring Data JPA - Reference Documentation

335p.

명령 쿼리 원칙은 지켜져야 한다.

버그를 예방할 수 있고, 행위를 쉽게 예측할 수 있다.

 

만약 상태 변경과 값 반환이 이뤄져야 한다면 2개의 메서드를 호출하는 제3의 메서드를 만드는 것이 더 좋은 방법이다.

 

338p.

매개변수를 메서드로 전환

 

이전에 소개한 것은 비슷한 기능을 하는 메서드를 하나의 메서드로 합치는 작업이었다.

이번 작업은 반대로 메서드 내부에서 여러 작업을 하고 있다면 각각 메서드로 분리하는 것이다.

 

이는 더 명확한 인터페이스를 갖게 된다.

단, 매개변수가 자주 바뀌는 상황이면 메서드로 분리하면 안 된다.

조건에 따라 달라짐으로 조건문을 재정의로 전환을 해야 한다.

 

342p.

매개변수를 객체로 전달 부분이다. 항상 고민을 하던 주제이다.

마틴 파울러가 말하는 객체로 보냈을 때의 장점은 나중에 수정이 간편하고, 넘겨지는 객체의 메서드도 이용 가능해서 중복 코드를 줄일 수 있다는 점이다.

 

단점은 의존성이 양방향이 된다는 점이다. 호출하는 쪽과 호출당하는 쪽. get으로 값을 빼올 테니

 

책을 읽어도 해결되지 않는 의문점은 만약 특정 객체를 넘기고

그 메서드를 여러 곳에서 사용해야 한다면 매개변수로 사용되는 객체는 항상 만들어져야 한다.

그럼 test를 위해서는 해당 객체 생성이 선작업이 되어야 하는데 이것이 맞는 것인지는 모르겠다.

 

매개변수로 원시 값을 보낼 때의 장점인 변경 방지를 객체 사용 때도 사용하려면 필드 값을 final로 사용하면 된다.

 

범위 패턴을 실습해보자.

 

 

이제 매개변수로 객체를 전달하기로 했다.

이제 기존 코드는 다음과 같이 변경된다.

 

근데 아직 뭔가 더 우아하지 않다. 저 조건은 누구의 책임으로 가는 게 맞을까? 

정보 책임자는 DateRange로 보이니 책임을 옮기자

 

 

 

 

https://github.com/ChoiGiSung/Refactoring/commits/main/src/main/java/chapter10/Account.java

GitHub - ChoiGiSung/Refactoring: 1판

 

362p.

팩토리 메서드 패턴의 이유를 여러 가지가 있겠지만

분류 부호를 하위 클래스로 변경했을 때 사용 가능하다.

생성자는 해당 인스턴스를 반환하지만 팩토리 메서드는 다른 인스턴스를 쉽게 반환할 수 있다.