Refactoring

메서드 호출 단순화

Refactoring - 메서드 호출 단순화

6 minute read

메서드 호출 단순화 객체에서 가장 중요한 것은 인터페이스. 이해와 사용이 쉬운 인터페이스를 작성하는 기술이야 말로 좋은 객체지향 소프트웨어 개발에 꼭 필요. 인터페이스를 더 쉽게 만드는 리펙토링 기법을 설명 함. 1. 메서드명 변경 Rename Method 1.1 동기 저자가 주장하는 코드 스타일의 가장 중요한 부분은 복잡한 과정을 여러 작은 메서드로 잘개 쪼개는것. 메서드를 쪼개는 과정을 잘못 적용할 경우 메서드의 역할을 파악하기 힘들어짐. 이런 문제를 방지하기 위해 메서드명을 잘 지어야함. 1.2 방법 메서드가 상위클래스나 하위클래스에 구현 되어 있는지 검사.

조건문 간결화

Refactoring - 조건문 간결화

6 minute read

  1. 조건문 간결화 조건문을 간호화 하는 리팩토링 종류 조건문을 여러 개로 나누는 조건문 쪼개기 여러 조건 검사가 있는데 결과가 모두 같을 땐 중복 조건식 통합 조건문 안의 중복 코드를 제거하려면 조건문의 공통 실행 코드 빼내기 특수한 case 조건문을 명확히 하려면 여러 겹의 조건문을 감시 절로 전환 복잡한 제어 플래그를 제거하려면 제어 플래그 제거 ** 1. 조건문 쪼개기 ** 복잡한 조건문 (if-then-else)이 있을 땐 if, then, else 부분을 각각 메서드로 빼내자 동기 프로그램에서 가장 복잡한 부분은 주로 복잡한 조건문이다.

데이타 체계화

Refactoring - 데이타 체계화

21 minute read

필드 자체 캡슐화 필드에 직접 접근하고 있는데 필드에 대한 결합이 이상해지면 get/set 메소드를 만들어 필드에 접근. 동기 직접 접근 방식 : 절차적인 개발진행중 데이타 변경이 일어날 수 있는 소지가 있음. 간접 접근 방식 : 객체지향 필드를 직접 접근하지 않으므로 정보 은닉 및 의도하지 않은 데이터 변경이 안된다. 필드 자체 캡슐화를 실시해야 할 가장 절실할 시점은 상위클래스 안의 필드에 접근하되 이 변수 접근을 하위클래스에서 계산된 값으로 재정의해야 할때다. 먼저 필드를 자체 캡슐화한 후 필요할때 읽기 메서드와 쓰기 메서드를 재정의하면 된다.

객체 간의 기능 이동

Refactoring - 객체 간의 기능 이동

13 minute read

객체 간 이동이 가능한 상황 및 상황별 리팩토링 기법 기능을 넣을 적절한 위치를 찾는 경우 메서드 이동(Move Method) 필드 이동(Move Field) 방대해진 클래스의 정리 또는 클래스 기능이 너무 적은 경우 클래스 추출(Extract Class) - 기능이 너무 많아 방대해진 클래스 클래스 직접 삽입(Inline Class) - 리팩토링 결과로 클래스 내에 기능이 너무 작아진 경우 다른 클래스로 합침 다른 클래스(대리 클래스)를 이용할 경우 대리 객체 은폐(Hide Delegate) - 대리 클래스가 사용 중이라는 것을 외부에 감춤 과잉 중개 메서드 제거(Remove Middle Man) - 대리 객체 은폐시 대리 클래스를 사용 중인 클래스의 인터페이스가 변경될 때 클래스의 원본 코드에 접근할 수 없는 상황에서 수정 불가능한 클래스의 기능을 이동해야 할 때 외래 클래스에 메서드 추가(Introduce Foreign Method) - 기능을 이동할 메서드가 한두개 뿐일 때 국소적 상속확장 클래스 사용(Introduce Local Extension) - 기능을 이동할 메서드가 세개 이상일 때 메서드 이동 (Move Method) 메서드가 자신이 속한 클래스보다 다른 클래스의 기능을 더 많이 사용할 때 → 그 메서드가 가장 많이 이용하는 클래스 안에서 비슷한 내용의 메서드를 작성 → 기존 메서드는 간단한 대리 메서드로 전환하던지 아예 삭제 동기 언제 적용하는게 좋을까?