[리팩토링] 냄새17,리팩토링37

냄새17. 메세지 체인 (Message Chains)

• 레퍼런스를 따라 계속해서 메소드 호출이 이어지는 코드

예) this.member.getCredit().getLevel().getDescription()

• 해당 코드의 클라이언트가 코드 체인을 모두 이해해야 한다. 
• 체인 중 일부가 변경된다면 클라이언트의 코드도 변경해야 한다. (getCredit() -> getRange() 메소드로 변한다면 모든 클라이언트 코드 변경 필요)
• 관련 리팩토링
  • "위임 숨기기(Hide Delegate)"를 사용해 메시지 체인을 캡슐화할 수 있다. : 클라이언트가 최소의 코드만 알아도 되게 
  • "함수 추출하기(Extract Function)"로 메시지 체인 일부를 함수로 추출한 후 함수 옮기기(Move Functioin)"으로 해당 함수를 적절한 이동할 수 있다.

리팩토링37. 위임 숨기기

• 캡슐화(Encapsulation)란 어떤 모듈이 시스템의 다른 모듈을 최소한으로 알아야 한다는 것이다. 그래야 어떤 모듈을 변경할 때, 최소한의 모듈만 그 변경에 영향을 받을 것이고, 그래야 무언가를 변경하기 쉽다. 
• 캡슐화 신경쓰지 않고 다양한 모듈에 산발적으로 코드가 흩어져 있다면, 관련 변경이 있을 때 모든 위치의 산발적인 코드를 다 변경해야 한다. (산탄총 수술 문제 발생할 수 있음) 
• 단 하나의 목적 : 클라이언트가 최소한의 정보만 알고, 원하는 정보를 호출할 수 있다. 내부 정보는 클라이언트에게 중요한 게 아니다.
• 처음 객체 지향에서 캡슐화를 배울 때 필드를 메소드로 숨기는 것이라 배우지만, 메소드 호출도 숨길 수 있다.
  • 이전의 코드는 Department를 통해 Manager에 접근할 수 있다는 정보를 알아야 하지만, getManager()를 통해 위임을 숨긴다면 클라이언트는 parson의 getManager()만 알아도 된다. 나중에 getManager() 내부 구현이 바뀌더라도 getManager()를 사용한 코드는 그대로 유지할 수 있다.

예) person().department().manager(); -> person.getManager();
// 추후에 getManager 내부 로직이 변경되더라도 클라이언트 변경은 없다. 
// department().getManger()호출부가 필드로 생성되어 변경이 일어나더라도

 

 

출처 : 백기선님 - 코딩으로 학습하는 리팩토링