모듈과 함수는 소프트웨어를 구성하는 빌딩 블록이며, API는 이 블록들을 끼워 맞추는 연결부다.
이런 API를 이해하기 쉽고 사용하기 쉽게 만드는 일은 중요하며 어렵다.
그래서 API를 개선하는 방법을 새로 깨달을 때마다 그에 맞게 리팩터링 해야한다.
11. 1 질의 함수와 변경 함수 분리하기
목표 : “부수 효과” 없애기
겉보기 부수 효과가 전혀 없이 값을 반환해주는 함수를 추구해야 함
Get함수 안에 set이 같이 있는 경우
11. 2 함수 매개변수화하기
두 함수의 로직이 아주 비슷하고 단지 리터럴 값만 다르다면?
하나의 함수로 만들고 중복 없애기
매개변수로 boolean값을 써서 제어에 쓰는 경우 아님
11.3 플래그 인수 제거하기
호출할 수 있는 함수들이 무엇이고 어떻게 호출해야 하는지를 이해하기가 어려워지기 때문
플래그 인수를 두 개 이상 사용한다면, 합당히 쓸만하다
근데 달리 보면, 함수 하나가 너무 많은 일을 하고 있음 -> 악취의 기운이 있음
11.4 객체 통째로 넘기기
변화의 대응을 쉽게하기 위한 리팩토링 기법
- 필요한 데이터가 달라져도 매개변수가 달라지지 않음
- 매개변수 목록이 짧아져 이해가 쉬워짐
- 중복된 로직을 없앨 수 있다
만약
- 함수가 레코드 자체에 의존하기 원치 않을 때
- 한 함수에, 객체에서 가져온 값 몇 개만으로 무엇을 할 때
-> 해당 값을 사용하는 객체에 옮겨주기 - 객체 전반에서 똑같은 값 몇 개만 사용하는 함수가 많다면
-> 부분 클래스를 추출하여 사용하기
11.5 매개변수를 질의 함수로 바꾸기
함수 밖에서 질의 함수로 값 받아 매개변수로 넘겨주지 말고,
함수 안에서 질의함수로 값 얻어오기
책임소재를 피호출함수(함수 안)로 옮기기
단, 이럴때 하지마라
- 매개변수를 제거하면 피호출 함수에 원치 않는 의존성이 생길 때
즉, 해당 함수가 몰랐으면 하는 프로그램 요소에 접근해야 하게 될 때
11.6 질의 함수를 매개변수로 바꾸기
더 이상 함수가 특성 원소에 의존하길 원치 않을 때
책임을 호출자로 옮기기
- 참조 투명성
똑같은 input에 매번 똑같은 output
11.7 세터 제거하기
무조건 접근자 메서드를 통해서만 필드를 다루려 할 때
클라이언트에서 생성 스크립트를 사용해 객체를 생성할 때
11.8 생성자를 팩터리 함수로 바꾸기
생성자보다 제약이 적다
-> 컨스트럭터를 경우에 따라 만들어야 하므로 코딩 수 줄어듬
11.9 함수를 명령으로 바꾸기
명령 객체로 코드 줄이기 + 의미 전달
=> 함수 잘게 쪼갤 수 있게 하기
함수를 명령으로 바꾸면 임시 변수들을 클래스 필드 변수로 옮길 수 있음
필드 변수는 객체 어디서든 가능하니, 쉽게 함수 추출이 가능함
- 일급객체
함수를 매개변수로 전달 가능한가
일급함수를 지원하지 않는 언어라면 유일한 선택
11.10 명령을 함수로 바꾸기
11.11 수정된 값 반환하기
- 부수효과 없애기
데이터가 수정된다면 그 사실을 명확히 알려줘야 함
그런데 함수 내부에서 바꿔버리면 알기 힘듬
리턴하게 해주고, 호출자가 그걸 받아서 set함
11.12 오류 코드를 예외로 바꾸기
예외를 사용하면 상단에서 모두 일일이 오류코드 검사할 필요 없음
예외는 정확히 예상 밖의 동작을 때만 쓰여야 함
11.13 예외를 사전확인으로 바꾸기
예외도 좋지만, 예외를 던지기 전에 확인하고 처리함
'Refactoring' 카테고리의 다른 글
[ 리팩토링 by 마틴 파울러 ] Chapter12. 상속 다루기 (0) | 2021.07.22 |
---|---|
[ 리팩토링 by 마틴 파울러 ] Chapter10. 조건부 로직 간소화 (0) | 2021.07.22 |
[ 리팩토링 by 마틴 파울러 ] Chapter09. 데이터 조직화 (0) | 2021.07.22 |
[ 리팩토링 by 마틴 파울러 ] Chapter08. 기능 이동 (0) | 2021.07.22 |
[ 리팩토링 by 마틴 파울러 ] Chapter07. 캡슐화 (0) | 2021.07.21 |