짧은 함수 vs 긴 함수
- 함수가 길 수록 더 이해하기 어렵다 vs 짧은 함수는 더 많은 문맥전환을 필요로 한다.
- "과거에는" 작은 함수를 사용하는 경우에 더 많은 서브루틴 호출로 인한 오버헤드가 있었다.
- 작은 함수에 "좋은 이름"을 사용했다면 해당 함수의 코드를 보지 않고도 이해할 수 있다.
- 어떤 코드에 "주석"을 남기고 싶다면, 주석 대신 함수를 만들고 함수의 이름으로 "의도"를 표현해보자.
사용할 수 있는 리팩토링 기술
- 대부분 함수 추출하기로 해결할 수 있다.
- 함수로 분리하면서 해당 함수로 전달해야 할 매개변수가 많아진다면 다음과 같은 리팩토링을 고려해볼 수 있다.
- 임시 변수를 질의 함수로 바꾸기
- 매개변수 객체 만들기
- 객체 통째로 넘기기
- 조건문 분해하기를 사용해 조건문을 분리할 수 있다.
- 같은 조건으로 여러개의 Switch문이 있다면, 조건문을
다형성으로 바꾸기를 사용할 수 있다. - 반복문 안에서 여러 작업을 하고 있어서 하나의 메소드를 추출하기 어렵다면
반복문 쪼개기를 적용할 수 있다.
1. 임시 변수를 질의 함수로 바꾸기
- 변수를 사용하면 반복해서 동일한 식을 계산하는 것을 피할 수 있고, 이름을 사용해 의미를 표현할 수도 있다.
- 긴 함수를 리팩토링 할 때, 그러한 임시 변수를 함수로 추출하여 분리한다면 빼낸 함수로 전달해야 할 매개변수를 줄일 수 있다.
2. 매개변수 객체 만들기
- 같은 매개변수들이 여러 메소드에 걸쳐 나타난다면 그 매개변수들을 묶은 자료 구조를 만들 수 있다.
- 그렇게 만든 자료구조는
- 해당 데이터간의 관계를 보다 명시적으로 나타낼 수 있다.
- 함수에 전달한 매개변수 개수를 줄일 수 있다.
- 도메인을 이해하는데 중요한 역할을 하는 클래스로 발전할 수도 있다.
3. 객체 통째로 넘기기
- 어떤 한 레코드에서 구할 수 있는 여러 값들을 함수에 전달하는 경우, 해당 매개변수를 레코드 하나로 교체할 수 있다.
- 매개변수 목록을 줄일 수 있다.
- 이 기술을 적용하기 전에 의존성을 고려해야 한다.
- 어쩌면 해당 메소드의 위치가 적절하지 않을 수도 있다.
4. 함수를 명령으로 바꾸기
- 함수를 독립적인 객체인 ,Command로 만들어 사용할 수 있다.
- 커맨드 패턴을 적용하면 다음과 같은 장점을 취할 수 있다.
- 부가적인 기능으로 undo 기능을 만들수도 있다.
- 더 복잡한 기능을 구현하는데 필요한 여러 메소드를 추가할 수 있다.
- 상속이나 템플릿을 활용할 수도 있다.
- 복잡한 메소드를 여러 메소드나 필드를 활용해 쪼갤 수도 있다.
- 대부분의 경우에 "커맨드"보다는 "함수"를 사용하지만, 커맨드말고 다른 방법이 없는 경우에만 사용한다.
5. 조건문 분해하기
- 여러 조건에 따라 달라지는 코드를 작성하다보면 종종 긴 함수가 만들어지는 것을 목격할 수 있다.
- "조건"과 "액션" 모두 "의도" 를 표현해야한다.
- 기술적으로는 "함수 추출하기"와 동일한 리팩토링이지만 의도만 다를 뿐이다.
6. 반복문 쪼개기
- 하나의 반복문에서 여러 다른 작업을 하는 코드를 쉽게 찾아볼 수 있다.
- 해당 반복문을 수정할 때 여러 작업을 모두 고려하며 코딩을 해야한다.
- 반복문을 여러개로 쪼개면 보다 쉽게 이해하고 수정할 수 있다.
- 성능 문제를 야기할 수 있지만, "리팩토링"은 "성능 최적화"와 별개의 작업이다. 리팩토링을 마친 이후에 성능 최적화를 시도할 수 있다.
7. 조건문을 다형성으로 바꾸기
- 여러 타입에 따라 각기 다른 로직으로 처리해야 하는 경우에 다형성을 적용해서 조건문을 보다 명확하게 분리할 수 있다. 반복되는 switch문을 각기 다른 클래스를 만들어 제거할 수 있다.
- 공통으로 사용되는 로직은 상위클래스에 두고 달라지는 부분만 하위클래스에 둠으로써, 달라지는 부분만 강조할 수 있다.
- 모든 조건문을 다형성으로 바꿔야 하는 것은 아니다.
