[리팩터링] 변수 캡슐화하기 필사

리팩터링은 결국 프로그램의 요소를 조작하는 일이다.

함수는 데이터보다 다루기가 수월하다.

함수를 사용한다는 건 대체로 호출한다는 뜻이고, 함수의 이름을 바꾸거나 다른 모듈로 옮기기는 어렵지 않다.

여차하면 기존 함수를 그대로 둔 채 전달 함수로 활용할 수도 있기 때문이다.

이런 전달 함수를 오래남겨둘 일은 별로 없지만 리팩터링 작업을 간소화하는데 큰 역할을 한다.

 

반대로 데이터는 함수보다 다루기가 까다로운데, 그 이유는 이런식으로 처리할 수 없기 때문이다.

데이터는 참조하는 모든 부분을 한 번에 바꿔야 코드가 제대로 동작한다.

짧은 함수 안의 임시 변수처럼 유효범위가 아주 좁은 데이터는 어려울 게 없지만, 유효범위가 넓어질수록 다루기 어려워진다.

전역 데이터가 골칫거리인 이유도 바로 여기에 있다.

 

그래서 접근할 수 있는 범위가 넓은 데이터를 옮길 때는 먼저 그 데이터로의 접근을 독점하는 함수를 만드는 식으로 캡슐화하는 것이 가장 좋은 방법일 때가 많다.

데이터 재구성이라는 어려운 작업을 함수 재구성이라는 더 단순한 작업으로 변환되는 것이다.

 

데이터 캡슐화는 다른 경우에도 도움을 준다.

데이터는 사용하는 코드를 감시할 수 있는 확실한 통로가 되어주기 때문에, 데이터 변경 전 검증이나 변경 후 추가 로직을 쉽게 끼워넣을 수 있다.

나는 유효범위가 함수 하나보다 넓은 가변 데이터는 모두 이런 식으로 캡슐화해서 그 함수를 통해서만 접근하게 만드는 습관이 있다.

 

데이터의 유효범위가 넓을수록 캡슐화해야 한다.

레거시 코드를 다룰 때에는 이런 변수를 참조하는 코드를 추가하거나 변경할때마다 최대한 캡슐화 한다.

그래야 자주 사용하는 데이터에 대한 결합도가 높아지는 것을 막을 수 있다.

 

객체 지향에서 객체의 데이터를 항상 private으로 유지해야한다고 그토록 강조하는 이유가 바로 여기에 있다.

나는 public 필드를 발견할 때마다 캡슐화해서 가시 범위를 제한하려 한다.

클래스 안에서 필드를 참조할 때조차 반드시 접근자를 통하게 하는 자가 캡슐화를 주장하는 사람도 있다.

개인적으로는 자가 캡슐화까지는 좀 지나치지 않다 생각한다.

필드를 자가 캡슐화해야할 정도로 클래스가 크다면 잘게 쪼개야 하기 때문이다.

하지만 클래스를 쪼개기 전 단계로써 필드를 자가 캡슐화하는 것은 도움이 된다.

 

불변 데이터는 가변 데이터보다 캡슐화할 이유가 적다.

데이터가 변경될 일이 없어서 갱신 검증같은 추가 로직이 자리할 공간을 마련할 필요가 없기 때문이다.

게다가 불변데이터는 옯길 필요없이 그냥 복제하면 된다.

 

그래서 원본 데이터를 참조하는 코드를 변경할 필요도 없고, 데이터를 변형시키는 코드를 걱정할 일도 없다.

불변성은 강력한 방부제인 셈이다.

 

절차

1. 변수로의 접근과 갱신을 전담하는 캡슐화 함수들을 만든다.

2. 정적 검사를 수행한다.

3. 변수를 직접 참조하던 부분을 모두 적절한 캡슐화 함수 호출로 바꾼다.

하나씩 바꿀 때마다 테스트 한다.

4. 변수의 접근 범위를 제한한다.

5. 테스트 한다.

6. 변수 값이 레코드라면 레코드 캡슐화하기를 적용할지 고려해본다.