2021.12.07~08 기록장

ToDo

• 책 읽기
•  

Done

• 책 읽기

Weekly goal

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

리팩터링

269p.

분류 부호를 하위 클래스로 전환

 

코드 내부에 존재하는 switch문을 분리할 수 있을 거다.

근데 클래스로 바꾸기 전에 클래스에 기능적으로 영향을 끼치는 지를 판단하고 끼치지 않는다면 (각자 하는 일이 단수 분류) enum으로 분류하고 반대라면 클래스로 분리하여 각자 각기 다른 일을 처리할 수 있다.

 

단순 혈액형은 enum으로 충분하지만 만약 혈액형별로 각자의 일이 존재한다면 하위 클래스로 분리할 수 있다.

 

273p.

분류 부호를 상태/전략 패턴으로 전환

 

위의 상황에서 하위 클래스로 전환할 수 없을 때 사용된다.

ex) 분류 부호가 수시로 바뀜

 

상태/전략 패턴과 하위 클래스로 전환은 어느 정도 비슷한 것 같다.

단 위에서도 말했듯이 분류 부호가 바뀔 경우 대비할 수 있으면 상태 전략, 그게 아니면 추가, 삭제만 된다면 하위 클래스 일 듯하다

클래스로 빼서 기능을 정의한다.

 

279p.

하위 클래스를 필드로 전환

단순한 기능을 하위 클래스로 빼면 오히려 복잡도가 증가한다.

분리를 할 때 중심을 잡기는 힘들어 보이는데 이는 직감에 맡겨야 할 듯하다. 책에도 직감을 언급한다.

286p.

if문 쪼개기

if문은 복잡해지기 쉽다. 그렇게 되면 코드는 이해되지만 왜 그렇게 되는지는 알기 힘들기에 적절한 명의 메서드로 분리해서 처리하자.

 

301p.

감시 절은 특정 if문이 true일 때 바로 반환하는 경우를 칭한다.

이는 리턴하는 부분이 증가됨을 의미한다.

 

310p.

null 검사를 널 객체에 위임

굉장히 흥미로운 주제이다. 또 구현은 아름답다.

 

예제를 보자.

가게는 직원이 있고 직원은 월급이 있다.

store가 주어졌을 때 직원은 있을 수도 없을 수도 있기에 null 검사가 이뤄질 것이다.

근데 이는 매번 검사를 해야 하는 작업이다.

이를 좀 우아하게 바꿔보자.

 

store에서 직원을 꺼낼 때 null 검사를 한다.

이때 없으면 null을 보내는 것이 아닌 null객체를 보낸다.

null객체는 null검사 메서드가 있기에 service에서 간단하게 메서드를 변경할 수 있다.

 

근데 아직까진 우아하지 않다. 좀 더 머리를 써보자.

 

null객체에서도 월급 객체를 반환할 수 있다.

이를 통해 service에서는 null객체인지 여부는 상관하지 않는다.

그저 월급 객체를 받아서 반환할 뿐이다.

 

좀 더 활용방법을 찾아봐야겠다. 좋은 코드 작성법인 것 같다.

ps) db에 없을 때 적용 방법이 있을까?

 

https://github.com/ChoiGiSung/Refactoring/commit/d0c1778f3f6e5cdedbe0c70a1aa79ed39b40d3f5

feat : null 객체를 위한 기본 세팅 · ChoiGiSung/Refactoring@d0c1778

 

319p.

어설션 넣기

메서드를 작성하다 보면 전제조건을 만족하고 다음 메서드를 실행시켜야 할 때가 있다.

근데 모듈화가 되어있기에 전제조건을 판단하는 코드를 다음 메서드에 넣기는 좀 그렇다.

책에서도 어설션은 개발할 때는 넣되 제품으로 발매할 때는 삭제한다고 되어있다.

 

이는 코드를 안전하게 할 수 있지만 오히려 코드 스멜이 될 수 있다.