코드의 구린내 - 2

.

<구린 게 있으면 그 부분을 바로 잡으세요>

7. 잘못된 소속(Feature Envy)

- 먼저 객체는 데이터(필드)와 그 데이터에 사용되는 프로세스(메소드)를 한 데 묶는 기술이 핵심이다.

- 어떤 메소드가 자신이 속하지 않은 클래스에 더 많이 접근한다면 잘못된 소속의 구린내가 풍길 것이다.

- 이 때는 더 많이 호출되는 클래스로 메소드르 옮기자.

- 메소드의 일부분만 그렇다면 메소드를 추출하여 적절한 클래스로 이동 조치한다.

.

.

8. 데이터 뭉치(Data Clumps)

- 데이터 항목은 거리의 꼬마들처럼 몰려다니는 습성이 있다. 

- 이렇게 몰려 있는 데이터 뭉치는 객체로 만들어야 한다.

- 음.. 와닿지는 않지만, 확실히 클래스로 추출한다면 코드가 가벼워질 것 같다.

.

.

9. 강박적 기본 타입 사용(Primitive Obsession)

- 객체를 처음 접하는 사람은 보통 숫자와 통화를 연동하는 돈 관련 클래스나 전화번호와 우편번호 같은 특수 문자열 클래스 등의 사소한 작업에 작은 객체를 잘 사용하지 않으려는 경향이 있다.

- 우물 안 개구리가 되지 않으려면 데이터 값을 객체로 전환해보자. 

.

.

10. switch 문(Switch Statements)

- 이녀석이 제일 문제인 것 같다. 중복코드를 대량생산하는 녀석이다.

- 객체지향 코드의 확연한 특징 중 하나는 스위치가 비교적 적게 사용된다는 점이다.

- 객체지향 개념 중 하나인 다형성(재정의)을 이용하는 방법이 최상이다. (다형성은 껍데기는 같으나 속이 다른 놈들로 이해하면 되겠다)

- 단, 간단한 스위치는 그냥 사용하는 것이 더 낫다.

.

.

11. 평행 상속 계층(Parallel Inheritance Hierarchies)

- 기능의 산재의 특수한 상황이다.

- 이 문제점이 있으면 한 클래스의 하위클래스를 만들 때마다 매번 다른 클래스의 하위클래스도 만들어야 한다.

- 음?

.

.

12. 직무유기 클래스(Lazy Class)

- 직무유기라는 표현이 재미있다.

- 하나의 클래스를 작성할 때마다 유지관리와 이해하기 위한 비용이 추가된다.

- 따라서 비용만큼의 기능을 수행하지 못하는 비효율적 클래스는 없어져야 한다.

.

.

13. 막연한 범용 코드(Speculative Generality)

- 이름에서 느낌이 온다. 쓸데 없는 일은 하지 말라는 뜻인 것 같다.

- 책에서는 - 막연한 생각에 아직은 필요 없는 기능을 수행하고자 넣는 온갖 호출과 case 문들- 이라고 예를 들어 놓았다.

.

.

14. 임시 필드(Temporary Field)

- 필드(전역변수, 멤버변수) 중에는 불필요하게 선언된 녀석들이 간혹 있다.

- 개발자가 편의(매개변수를 줄이려는 행위)를 위해 선언하기도 한다.

- 이런 가엾은 떠돌이 변수들에게 서식할 집을 마련해 주자. -> 클래스 추출

.

.

15. 메시지 체인(Message Chains)

- 클라이언트가 한 객체에 제 2의 객체를 요청하면, 제 2의 객체가 제 3의 객체를 요청하고 그 과정이 연쇄되어 발생하는 문제점

- 객체가 어느 대상에 사용되는지를 알아내 리팩토링하자.

- 사실 잘 모르겠다.

.

.

.