리팩터링 2판을 회사 팀 내 스터디로써 진행한다. 스터디에선 따로 책 내용을 정리를 하지 않고 주마다 정해진 분량까지 읽고 감상을 나눈다. 여기선 개인적으로 매 분량에 대한 정리와 짧은 감상을 올린다.
07 캡슐화
•
캡슐화, “자신을 제외한 다른 부분에 드러내지 않아야 할 비밀을 얼마나 잘 숨기느냐”로써의 모듈화
•
기본형을 객체로 바꾸면 단순 데이터 클래스로써만이 아니라 메소드를 정의하여 생기는 부수적인 효과가 크다.
•
위임 숨기기 - 클래스 사이 연결 관계의 캡슐화
•
vs. 중개자 제거하기 - 연결을 드러내어 인터페이스를 간소화
7.1 레코드 캡슐화하기
•
레코드가 “가변” 데이터일 경우 객체로 쓰기 위해 클래스로 캡슐화
•
필드 대신 메서드(접근자, 변경자)의 장점 - 수정이 쉽다
•
쓰기 다루기
◦
읽기 프락시 구성하기
◦
접근자에서 복사본 반환하기
•
◦
데이터 변환(직렬화, 역직렬화)의 캡슐화를 통한 리팩터링
7.2 컬렉션 캡슐화하기
•
컬렉션 원본 자체를 접근자가 반환하면 수정했을 때 문제가 생길 수 있다
◦
복사본을 반환하자
◦
읽기 전용 프락시를 쓰자
◦
변경자를 쓰자
•
언어의 컬렉션 표준 인터페이스와 파이프라인을 사용하자
◦
전용 메서드를 정의하면 나중에 비용이 많이 든다
7.3 기본형을 객체로 바꾸기
•
단순한 숫자, 문자 같은 기본형이 코드가 커지다 보면 클래스로써 다루고 싶어진다
◦
로직(=메서드로 만들 부분)이 생기기 때문
•
귀찮다고 느껴질 수 있지만 리팩터링 중 가장 유용하다
7.4 임시 변수를 질의 함수로 바꾸기
•
결과값을 “다시” 참조할 목적의 임시 변수를 쓴다 → 그럴거면 함수 호출
•
임시 변수의 경계에 있는 함수 추출을 쉽게 만든다. 인자로 넘기지 않아도 되어서
◦
이렇게 추출하면 부자연스러운 의존 관계, 부수효과를 제거 가능하다.
•
클래스에서 추출 시 공유 컨텍스트를 제공한다(this를 통한 접근)
•
변수 값은 한 번만 계산하고 그 뒤로 읽기만 해야 한다
◦
그러지 않고 계속 대입한다면 질의 함수로 추출해야 한다.
느낀점
•
레코드든 컬렉션이든 데이터를 다룰 때의 캡슐화에 대한 설명이다
◦
가변 데이터는 바뀔 것을 생각해서 단순한 필드를 메서드로 처리하게 끔
◦
▪
데이터를 클래스로 표현하고 객체화 + 리팩터링하면서 생기는 이점
▪
DTO도 이 중 하나가 아닐까
•
컬렉션 표준 인터페이스와 언어, 라이브러리가 제공하는 파이프라인을 잘 사용하자
◦
range 클래스는 만들까 말까하는 영역이었다면 이건 확실히 그러면 된다
◦
표준 인터페이스 - 
martinfowler.combliki: List And Hash
A strength of the list and hash structure is that you can manipulate it with generic operations which know nothing of the actual keys present. These operations can then be parameterized with the keys that you wish to manipulate. The generic operations, usually arranged into a collection pipeline, provide a lot of navigation features to allow you to pluck what you need from the data structure without having to manipulate the individual pieces.
◦
•
데이터 관련 프레임워크를 안쓰고 있는거 같다?
◦
아예 데이터 모델을 다루는 프레임워크나 디자인 패턴?(dto) 위에서 작업하는게 편한거 같기도(믿어선 안될 말)
◦
디자인패턴을 도입해보자?
•
임시 변수를 언제 잘못 쓰고 있는지 판단하는게 중요할거 같다