06. 기본적인 리팩터링

느낀점#

  • 이름 잘짜고 싶다
  • 불변 데이터는 다루고 쉽다
  • 매개변수가 다같이 이동할 땐 값 객체를 만드는 것을 고려
  • 테스트하기 쉽도록 메소드를 구성하는 연습을 해야겠다

6.1 함수 추출하기#

최적화를 할 때는다음 두 규칙을 따르기 바란다. 첫 번째, 하지 마라. 두 번째(전문가 한정), 아직 하지마라

  • M. A. 잭슨
  • 반대 리팩터링: 6.2 함수 인라인하기
  • 말 그대로 특정 목적이 있는 코드 묶음을 함수로 추출하는 것
  • 독립된 함수로 추출하고 목적에 맞는 이름 붙이기
    • 어떻게가 아닌 무엇을에 집중
  • 목적과 구현을 분리하는 방식이 가장 합리적인 기준

6.2 함수 인라인하기#

  • 반대 리팩터링: 6.1 함수 추출하기
  • 의미 없는 함수를 풀어헤치는 것
  • 쓸데 없는 간접 호출은 거슬릴 뿐이다

6.3 변수 추출하기#

  • 반대 리팩터링: 6.4 변수 인라인하기
  • 표현식이 너무 복잡하여 이해하기 어려울 때, 변수를 추출하여 이름을 지어주면 코드의 목적확인이 더 쉬워짐
  • 주의사항
    • 추출하려는 표현식에 부작용 없는지 확인
    • 불변 변수를 선언하고 해당 표현식을 추출하자

6.4 변수 인라인하기#

  • 반대 리팩터링: 6.3 변수 추출하기

6.5 함수 선언 바꾸기#

  • 함수 이름 바꾸기
  • 이름이 좋으면 호출문만 보고도 무슨일을 하는지 파악 가능
  • 주석을 통해 함수목적을 설명해보면 이름도 잘생각난다고 함
  • 함수 선언을 바꿀 대상이 너무 많은 곳에서 쓰여 다 파악하지 못하겠다면, 새로운 함수로 카피 후 선언을 바꾼다. 그리고, 파악 가능한 곳만 새로운 함수로 대체한다
    • 이때 기존 함수는 새로운 함수 콜의 형태로 변경한다
    • 모든 클라이언트가 바꾸었다 확신이 들때 기존 코드를 삭제한다
/** 함수 선언 바꿀 대상 */
public double circum(double radius) {
return circumference(radius);
}
/** 새로운 함수로 추출 */
public double circumference(double radius) {
return 2 * Math.PI * radius;
}

6.6 변수 캡슐화하기#

  • 필드 캡슐화
  • 데이터 사용 범위가 넓다면 적절히 캡슐화하자
  • 데이터 변경, 사용의 감시가 용이
  • 캡슐화 시 데이터 접근에 대한 확실한 통로역할을 해줌
  • 검증, 변경 후 로직등을 넣기 용이
  • 불변데이터는 가변데이터보다 캡슐화할 이유가 적다
  • 필드 수정은 가능하게 하고 싶으나 외부에 get을 이용해 객체를 받아 수정을 불가능하게 하고 싶으면?
    • get 시, 해당 필드의 카피본을 가져가게 한다

6.7 변수 이름바꾸기#

  • 제목이 내용이라 생략

6.8 매개변수 객체 만들기#

  • 어떤 데이터 세트가 매개변수로 자주 묶여 발생한다면 객체로 묶어주자
  • 객체로 묶는다면 개념이 추상화되서 더 개념적이게 되고 가독성도 좋아진다

6.9 여러 함수를 클래스로 묶기#

  • 클래스로 묶을 때 장점
    • 객체의 핵심 데이터를 변경할 수 있음
    • 파생 객체들을 일관되게 관리 가능

단일 접근 원칙#

한 모듈에서 제공하는 모든 서비스는 저장된 값인지, 계산된 값인지 상관없이 단일한 방식으로 접근이 가능해야 한다. - https://martinfowler.com/bliki/UniformAccessPrinciple.html

6.10 여러 함수를 변환 함수로 묶기#

  • 데이터를 입력받아서 여러가지 정보를 도출을 자주하게 됨
    • 이런 패턴이 반복될 경우 한 함수에 모아두는 것을 말함
    • 이때 한 함수를 변환 함수라 부름
  • 이 방법 보단 6.10의 클래스로 묶기를 더 권장
  • 변환 함수로 묶는 이유
    • 도출 로직이 중복되는 것을 피하기 위해

6.11 단계 쪼개기#

  • 서로 다른 두 대상을 한꺼번에 다룰땐 별개 모듈로 나누는 방법을 모색
  • 긴 코드 스텝들을 단계별로 메소드화 시켜 쪼개는 것을 말함
  • 단계를 쪼갤 시 테스트가 용이하도록 구성
  • 핵심은 단계를 분리한다는 것에 있음
    • 중간 통신용 객체를 말든던 단순히 그대로 파라미터를 전달하던 선호하는 것은 없다고 함

험블 객체 패턴 (Humble Object Pattern)#

https://martinfowler.com/bliki/HumbleObject.html

  • 크고 느린 작업에서 자주 테스트해야할 복잡한 동작을 분리하여 테스트를 쉽게 만드는 패턴
  • Json 예제에서 실제 동작부분을 메인에서 분리하여 테스트를 더 용이하게 함
Edit this page
Last updated on