[Refactoring] 리팩토링 7장 객체 간의 기능 이동

# 개요

리팩토링 7장, 객체 간의 기능 이동 읽고 간단 정리

각 카탈로그에서 설명하는 내용 중 중요하게 생각하는 부분 작성하고 내 생각도 덧붙임

코드 작성하다가 이 예시가 이거구나 싶을 때는 예시코드도 붙일 예정

 

# 객체 간의 기능 이동

객체 설계에서 가장 중요한 일 중 하나가 '기능을 어디에 넣을지 판단'하는것이다.

• 20년간 작업해 왔는데도 아직 서툴다고한다. 개 구라같지만 그만큼 어렵다는 뜻이겠지

클래스가 방대해지는 원인은 대체로 기능이 너무 많기 때문이다. 이럴 때는 클래스 추출을 통해 많은 기능을 분리 해야 한다.

• 확실하진 않지만 OOP 원칙중 SRP에 해당하는 내용인것 같다.
• 메서드와 마찬가지로 클래스도 작아야한다고 생각한다. 메서드가 점점 길어질 때 메서드를 분리해야하는 것처럼 한 클래스에 기능이 점점 늘어나면 클래스도 분리해야한다.

 

## Move Method (메서드 이동)

한 클래스에 기능이 너무 많거나 클래스가 다른 클래스와 과하게 연동되어 의존성이 지나칠 때는 메서드를 옮기는 것이 좋다.

• 객체간의 의존도를 줄이는 일은 항상 어렵다. 작은 프로젝트에서도 어려운데 규모가 커지면 더 어렵겠지..
• 한 클래스는 하나의 책임을 가져야 한다는 말이 아직 잘 와닿진 않지만 클래스 이름에 무언가 맞지 않는 기능을 하는 메서드가 있다면, 그 메서드는 그 클래스에 있어야 할 메서드가 아니라는 생각을 한다.

 

## Move Field (필드 이동)

지금은 합리적이고 올바르다고 판단되는 설계라도 나중에는 그렇지 않을 수 있다. 문제는 그게 아니라 그러한 상황 변화에 아무런 대처도 하지 않는 것이다.

• 내가 한 대부분의 프로젝트들은 한 번 하고 치워버리는 성향이 강했다. (과제나 그냥 작은 토이프로젝트..) 설계도 간단하고 설계가 변하는 일도 없었다. 과제같은 경우는 오히려 설계는 교수나 조교들이 다 했지 ㅋㅋ..
• 설계가 항상 변할 수 있다는 생각도 중요하고 어느 상황에나 유연하게 대처할 능력이 필요하다고 생각한다.

 

## Extract Class (클래스 추출)

클래스는 확실하게 추상화 되어야 하며, 두 세가지 명확한 기능을 담담해야 한다.

• 내가 이해하는 추상화는 그 클래스명, 메서드명만 보고도 이 모듈이 어떤 기능을 하는지 이해할 수 있도록 코드를 작성하는 것이다.
• 그만큼 메서드명, 클래스명을 잘 짓는것이 중요하고, 클래스에 맞는 메서드들만 가지고 있어야한다고 생각한다. 그러면 내부 구현이 어떤 로직인지 자세히 알 필요없다. 이 모듈이 뭘 하는지 이름만 보고도 아니깐

데이터의 일부분과 메서드의 일부분이 한 덩어리이거나 주로 함께 변화하거나 서로 유난히 의존적인 데이터의 일부분도 클래스로 떼어내기 좋다.

 

## Inline Class (클래스 내용 직접 삽입)

주로 클래스의 기능 대부분을 다른 곳으로 옮기는 리팩토링을 수행하고 남은 기능이 거의 없어졌을 때 나타난다.

 

## Hide Delegate (대리 객체 은폐)

캡슐화란 객체가 시스템의 다른 부분에 대한 정보의 일부분만 알 수 있게 은폐하는 것을 뜻한다. 객체를 캡슐화하면 무언가를 변경할 때 그 변화를 전달해야할 객체가 줄어듦으로 변경하기 쉬워진다.

클라이언트가 서버 객체의 필드 중 하나에 정의된 메서드를 호출할 때 클라이언트는 이 대리 객체에 관해 알아야 한다. 대리 객체가 변경될 때 클라이언트도 변경해야 할 가능성이 있기 때문이다. 이런 의존성을 없애려면 대리 객체를 감추는 간단한 위임 메서드를 서버에 두면 된다. 변경은 서버에만 이뤄지고 클라이언트에는 영향을 주지 않는다.

• 음 쉽게 생각하면 a객체 내에 있는 b객체의 메서드를 쓰기위해서 a.getB().somethingMetodOfB()이런 식으로 열거해서 쓰는것 보다. a 내의somethingMethod()에서 b객체의 메서드를 사용하는것이 좋다는 얘기 같다.

 

## Remove Middle Man (과잉 중개 메서드 제거)

대리 객체 사용을 캡슐화하면 얻는 장점도 있지만 단점도 생긴다. 클라이언트가 대리 객체의 새 기능을 사용해야 할 때마다 서버에 간단한 위임 메서드를 추가해야 한다는 점이다.

은폐의 적절한 정도를 알기란 어렵다. 하지만 리팩토링을 실시할 때는 은폐의 정도를 잘 몰라도 된다. 시스템이 변경되면 은폐의 정도의 기준도 변한다. 전에는 적절했던 캡슐화가 현재 시점에서는 부적절할 수도 있다. 리팩토링은 필요해질 때마다 보수하면 된다.

• 리팩토링 하고 후회하지 말라고 하는것 같다. 어짜피 다시 롤백하면 되니까
• 근데 말처럼 안된다 리팩토링하고 "이게 맞나? 전의 코드가 더 낫지않나?" 라는 고민을 할 때가 자주 있다.

 

## 내 생각

메서드 내에서만 해결하면 됐던 리팩토링에서 클래스로 옮겨가면 조금씩 어려워진다. 이게 클래스가 적으면 그러려니 하겠는데 프로젝트에서 클래스가 적을리가..

여기에 이제 디자인 패턴, OOP 원칙 등 더 머리 아파지는게 나오면 머리에 과부하오는데 리팩토링을 이해하기 위해서 선행 학습이 어느정도 필요한것 같다 ㅜ