개발서적 - 객체지향의 사실과 오해

* 본 포스팅은 지극적으로 개인적 견해임을 사전에 알립니다.

읽게 된 이유?

필자가 TDD를 연습하던 도중 굉장히 혼란스러웠던 적이 많았다.

TDD에 대한 설명은 해당 링크

TDD는 테스트 코드를 짜고, 컴파일 되지 않게 프로덕션 코드를 완성하고, 다시 리팩토링하는 과정이다.

하지만 굉장히 큰 난관에 봉착했다.

---

도대체 뭘 테스트 해야 되지?????

---

필자가 지금까지 해온 프로그래밍 절차는

1. 필드값을 가지는 객체를 정의한다.
2. 객체를 설계한다.
3. 테스트 케이스에 대한 모든 예외 처리 코드를 작성한다.

그러다 보니, 되게 많은 의문점이 들었다.

• 생성자를 테스트하는 것인가?
• 필드 변수에 List가 있으면, List에 add 되는 것을 테스트하는 것인가?
• 필드 변수에 제대로 저장이 되는지 테스트하는 것인가?
• 인스턴스의 Reference를 테스트하는 것인가?

@-@

TDD를 짜려다가 혼란이 왔었다. 분명 이러려고 TDD를 하는게 아닌데 하는 생각이 들었다.

그래서 객체의 본질을 내가 잘못 이해하고 있는 것은 아닌가? 하는 생각이 들었다

객체

기린 객체?

책을 요약하면 정말 세줄로 요약된다

행동이 상태를 결정한다.

따라서, 객체를 결정하는 것은 행동이다.

데이터는 단지 행동을 따를 뿐이다.

객체를 설계할 때

객체의 인스턴스 필드값을 먼저 생각하는게 아니라, 행위를 먼저 생각하고 필드를 추가하는 것이다

그리고 그 필드는 항상 바뀔 수 있다.

 

그렇기에 내가 TDD를 못짠 것이다.

나는 자꾸 인스턴스 필드를 먼저 지정하고, 테스트 하려 했던 것이다!!!

 

설계하는 과정

우리는 개발자니까 바로 과정부터 보러 가자

- 스마트폰은 여러가지 기능이 있지만, 그 중에서도 전원을 키는 기능(행위)를 실시한다고 하자!

- 전원을 키기 위해서는 배터리 정보(인스턴스)가 필요하다!! 

- 따라서 In으로 Battery정보를 기입하고, Out으로 켜지는지 여부를 판단하자!

1. 실패하는 테스트 코드 부터 작성

2. 컴파일만 되게 프로덕션 코드 작성

3. 실패

4. 프로덕션 코드 리팩토링

5. 성공

간단하게 TDD를 작성에 성공했다!

* 우리가 TDD가 어려웠던 이유는 뭘까?

바로 객체의 행위를 먼저 생각하지 않고, 필드부터 생각했기 때문이다

필드만 저장하는 객체는 데이터베이스와 다를게 없다. 그러니까 행위를 부여하자 꼭 꼭 꼭!!