Code Smell 04.

코드에서 나는 악취 목록

19. Insider Trading

일이 돌아가게 하려면 거래가 이뤄질 수밖에 없지만, 그 양을 최소로 줄이고 모두 투명하게 처리해야 한다.

커피 자판기 옆에서 은밀히 데이터를 주고받는 모듈들이 있다면 함수를 옮기거나 필드를 옮겨서 둘을 떼어놓아 사적으로 처리하는 부분을 줄인다. 여러 모듈이 같은 관심사를 공유한다면 공통부분을 정식으로 처리하는 제3의 모듈을 새로 만들거나 위임을 숨겨 다른 모듈이 중간자 역할을 하도록 한다.

상속 구조에서는 부모 자식 사이에 결탁이 생길 때가 있다. 자식 클래스는 항상 부모 클래스가 공개하고 싶은 것 이상으로 부모에 대해 알려고 한다. 그러다가 부모 품을 떠나야 할 때가 온다면 서브클래스를 위임으로 바꾸거나 슈퍼클래스를 위임으로 바꾸자.

20. Large Class

한 클래스가 너무 많은 일을 하려다 보면 필드 수가 상당히 늘어난다. 그리고 클래스에 필드가 너무 많으면 중복 코드가 생기기 쉽다.

이럴 때는 클래스를 추출하여 필드들 일부를 따로 묶는다. 같은 컴포넌트에 모아두는 것이 합당해 보이는 필드들을 선택하면 된다. 이렇게 분리할 컴포넌트를 원래 클래스와 상속 관계로 만드는 게 좋다면 슈퍼클래스를 추출하거나 타입 코드를 서브클래스로 바꾸는 것이 편리하다.

클래스가 항시 모든 필드를 사용하지는 않을 수도 있다. 이럴 때는 앞에서 언급한 추출 기법들을 여러 차례 수행해야 할지도 모른다.

필드가 너무 많은 클래스와 마찬가지로 코드량이 너무 많은 클래스도 중복 코드와 혼동을 일으킬 여지가 크다. 가장 간단한 해법은 그 클래스 안에서 자체적으로 중복을 제거하는 것이다.

21. Alternative Classes with Different Interfaces

클래스를 사용할 때의 큰 장점은 필요에 따라 언제든 다른 클래스로 교체할 수 있다는 것이다. 단, 교체하려면 인터페이스가 같아야 한다. 따라서 함수 선언을 바꾸어 메서드 시그니처를 일치시킨다. 때로는 이것만으로 부족한데, 이럴 때는 함수를 옮겨 인터페이스가 같아질 때까지 필요한 동작들을 클래스 안으로 밀어 넣는다.

22. Data Class

데이터 클래스란 데이터 필드와 게터/세터 메서드로만 구성된 클래스를 말한다. 그저 데이터 저장 용도로만 쓰이다 보니 다른 클래스가 너무 깊이까지 함부로 다룰 때가 많다. 이런 클래스에 public 필드가 있다면 누가 보기 전에 얼른 레코드를 캡슐화하여 숨기자. 변경하면 안 되는 필드는 세터를 제거하여 접근을 원천 봉쇄한다.

23. Refused Request

상속 포기 냄새는 서브 클래스가 부모의 동작을 필요로 하지만 인터페이스는 따르고 싶지 않을 때 특히 심하게 난다. 구현을 따르지 않는 것은 이해할 수 있지만 인터페이스를 따르지 않는다는 것은 상당히 무례한 태도다. 이럴 때는 서브클래스를 위임으로 바꾸거나 슈퍼클래스를 위임으로 바꾸어 상속 메커니즘에서 벗어나 보자.

24. Comments

주석을 달면 안 된다고 말하려는 건 아니니 걱정하지 말자. 주석은 악취가 아닌 향기를 입힌다. 문제는 주석을 탈취제처럼 사용하는 데 있다. 주석이 장황하게 달린 원인이 코드를 잘못 작성했기 때문인 경우가 의외로 많다.