클래스 간의 책임 소재를 나누는 리팩토링 기법에 대한 마틴 파울러의 이야기

1. Refactoring
Chapter # 7
클래스 간의 책임 소재를 나누는 Refactoring

2. Index
• Move Method
• Move Field
• Extract Class
• Inline Class
• Hide Delegate
• Remove Middle Man
• Introduce Foreign Method
• Introduce Local Extension

3. Move Method & Move Field
• Move Method
• 메소드가 자신이 정의된 클래스보다 다른 클래스의 기능을 더 많이 사
용하고 있을 경우, 해당 메소드를 다른 클래스로 옮겨주는 refactoring
기법
• Move Field
• 필드가 자신이 정의된 클래스보다 다른 클래스에 의해 더 많이 사용되
고 있는 경우 해당 필드를 빈번히 사용되는 다른 클래스로 옮겨주는
refactoring 기법
경우에 따라 Self Encapsulation을 사용해야 하는 상황도 생긴다. 하지만…
 원본 클래스의 책임과 역할을 더욱 분명히 만드는데 가장 기
본적인 Refactoring 기법

4. Extract Class & Inline Class
• Extract Class
• 두개의 클래스가 할 일을 하나의 클래스가 맡아서 하고 있는 경우, 클
래스를 분리하고 기능을 분리하는 refactoring 기법
무리하게 클래스를 추출하다 보면 간혹 상호 참조가 일어날 수 있는데, 이런 부분은 도리어 가독성을 떨
어뜨릴 수 있다. 가급적이면 sub-typing이 나을 것.
• Inline Class
• Extract Class와 반대의 개념으로 쪼개고 쪼개다 보면 기능이라고 할 것
조차 남지 않는 클래스가 생길 수 있는데, 이럴 때 해당 클래스를 자주
사용하는 다른 클래스와 Merging해 주는 refactoring 기법
Merging을 하는 과정에서 타 클래스의 참조가 없다면 inner class등을 통해 해당 class를 은닉하는 것도
좋음

5. Hide Delegate & Remove Middle Man
• Hide Delegate
• 클래스 사용자가 해당 클래스를 통해 다른 클래스를 얻고 그의 기능을 이용하
려 할 때, 위임 메소드를 통해 다른 클래스의 존재를 숨겨주는 refactoring 기
법
• OOP의 관점에서 보았을 때 자료(정보)은닉의 효과를 취할 수 있다.
이는 곧 클래스 사용자 입장에서 불필요한 정보를 줄여 주는, 사용하기 편리하게 만
들어 주는 역할
• Remove Middle Man
• Hide Delegate의 반대 개념으로 어떤 클래스가 Hide Delegate를 너무 많이
수행하여 본래 역할이 아닌 broker 역할처럼 보여 질 때, 클래스를 분리하여
broker 역할을 제거하는 refactoring 기법
broker 역할을 수행하더라도 해당 클래스의 본래의 취지(책임)에 부합이 된다면 굳이 제거하지 않는 쪽
이 나을 것 같다.

6. Introduce Foreign Method & Introduce
Local Extension
• Introduce Foreign Method
• 클래스를 수정할 수 없는 상황에서 선택하는 임시방편적인 기법으로, 특정 메
소드를 사용자측에 만든 후 첫 번째 인자로 원래 있어야 할 위치의 클래스를
받아서 처리 하도록 하는 방법
이 기법을 사용하여 추가한 메소드에는 주석 등을 통해 표시해 두고 클래스 내에서도 특정 구역으로 구
분해 두는 것이 유익하다.
• Introduce Local Extension
• 수정이 불가능한 특정 클래스에 지나치게 많은 Foreign Method를 많이 추가
해야 하는 경우 선택하는 기법으로, 해당 클래스를 상속받거나 Wrapping하여
메소드를 추가하는 방법
Introduce Foreign Method 방식보다 좀더 보편적이고 OOP 관점에서 보았을 때도 무리가 없는 방법.
wrapper를 사용하느냐 상속을 받느냐 선택은 어떻게 하는 것이 좋을까? 굳이 Wrapping을 사용해야 하
는 경우는??