9. 기능 질투(feature envy)
-> 원래 기능 편애라고 번역됨
모듈 구조에서 모듈 사이의 상호작용은 최소로 하고 모듈 내부의 상호작용은 최대로 하는 것이 좋은 구조이다.
이 악취는 어떤 메서드가 자신이 속한 객체의 메서드, 필드보다 다른 객체의 메서드와 더 많이 상호작용할 때 발생한다.
외부와의 상호작용이 많을수록 캡슐화가 깨져서 디버깅하기 어려워진다.
또한 뒤엉킨 변경(하나의 모듈이 여러 기능 변경에 영향을 받는 경우), 산탄총 수술(하나의 기능 변경에 여러 모듈이 영향을 받는 경우)의 신호일 수도 있다.
보통 getter 메서드 호출이 많다면 기능 질투를 의심해볼 수 있다.
getter 메서드를 사용한다는 것은 인터페이스 기반 접근이 아니라 구현 디테일에 접근한다는 것으로 제한적으로 쓰는 것이 좋다.
10. 데이터 뭉치
어떤 데이터들이 패거리를 이루며 여러 곳에서 몰려다닐 때 맡을 수 있는 냄새이다.
이런 데이터들을 하나의 데이터 구조로 묶어주면 향긋한 냄새를 맡을 수 있다.
객체 지향의 네 가지 이점(추상화, 캡슐화, 상속, 다형성)이 바로 그것이다.
11. 기본형 집착
데이터가 기본형으로 존재해서 객체들의 세계에서 동떨어져 있다면 이 악취를 풍기는 것이다.
이것도 데이터 뭉치와 마찬가지로 사용자 정의 데이터 구조로 정의해주면 좋다.
12. 반복되는 switch문
switch문의 지독함은 많은 사람들이 알고 있을 것이다.
switch문은 변경에 취약하다. 왜냐면 Open-Closed principle을 위배하기 때문이다.
OCP는 소프트웨어가 확장에는 열려 있고 변경에는 닫혀 있어야 한다는 원칙이다.
예를 들어 금융 상품을 조건 타입으로 switch문 100개를 사용하고 있다고 가정하자.
이때 금융 상품이 새롭게 하나 추가된다면 우린 100개의 switch문을 찾아다니며 바꿔야 한다.
아마 양떼 목장에서 양을 세는 것보다 어려울 것이다.
하지만 이를 다형성으로 구현하면 우린 그저 인터페이스를 구현한 클래스 하나만 추가로 정의하면 된다.
13. 반복문
반복문은 대표적인 명령형 프로그래밍 컴포넌트이다.
반복문을 사용하면 어떤 일을 해야할지 집중하게 된다.
이와 반대로 파이프라인을 사용하면 무슨 일을 해야할지 집중할 수 있다.
한단계 높은 추상화를 제공하는 것이다.
14. 성의 없는 요소
본문 코드를 그대로 쓰는 것과 다를 바가 없는 함수, 메서드가 하나뿐인 클래스 등은 오히려 구조를 복잡하게 만든다.
코드를 수정했거나 바로 이후에 나올 추측성 일반화의 결과인 경우가 많다.
이런 경우 인라인 하는 것이 좋다.
15. 추측성 일반화
우리가 알고 있는 Overprogramming이 이에 해당한다.
'미래에 이런 기능이 필요하겠지'라는 생각으로 하는 일이 거의 없는 추상 클래스 정의 등의 행위를 말한다.
이런 경우 프로그램을 복잡하게 만들기에 제거하는 것이 좋다.
미래보다는 현재에 집중하도록 하자.
16. 임시 필드
특정 상황에서만 값이 채워지는 필드가 있을 수 있다.
이런 경우 사용되지 않아 보이는 필드의 존재 이유를 파악하느라 코드를 이해하기가 어려워진다.
