[Chapter05] 여러분들은 구현할 때 어떤 과정으로 하시는지 궁금하네요.

[pythonstrup]

내용

• "상태보다 행동이 중요하다"
• 책에서 구현을 할 때도 메소드를 먼저 구현한 다음에 여기에 필요한 인스턴스 변수를 결정하더라고요?
  • 구현에서도 설계와 비슷한 flow를 가져가는 게 인상적이었습니다.

질문

• 여러분들은 객체를 구현할 때 어떻게 하시나요? 상태 먼저 정의하시나요? 책에서처럼 메소드를 먼저 정의하나요?
• 구현의 flow를 설계와 비슷하게 가져갔을 때 장점이 있을까요?
  • 사실 설계할 때 메시지가 정의되어 있고 그에 따른 상태값도 대충 정해져 있을텐데 굳이 flow를 동일하게 가져가야 하나? 라는 의문이 들었어요.

[JisuPark-dev]

저는 지금까지 객체지향을 고려하지 않고 코드작성을 해왔어서 위에서부터 필드, 메서드 순으로 쭉 작성했던 것 같아요. 하지만, 메서드 부터 작성한다고 상상했을 때 장점을 생각해본다면 내가 설계한 흐름을 한번 더 따라가면서 설계를 복습>? 한다는 느낌이 드네요. 그러면서 메세지의 흐름이 논리적으로 이상하다거나, 생각지 못한 필드를 추가할 수 도 있을 것 같아요.

[YJGwon]

저는 보통 메서드 먼저 정의해요. 흔히 top-down이라고 말하는 순서대로 구현하는 편입니다. client쪽의 흐름부터 작성하는데, 이 때는 수신할 객체가 어떻게 구현할 수 있을지는 고려하지 않아요. 수신할 객체가 갖고 있지 않은 메서드라도 일단 메시지와 client가 넘겨줄 수 있는 parameter, 돌려받을 return type 먼저 쭉 써봐요(이거 줄테니까 저거 내놓으라는 도둑놈 심보로 일단 작성합니다). 호출할 메서드에 대한 구현은 그 다음에 해요.

이렇게 하면 수신 객체의 내부 사정이 client쪽에 영향을 좀 덜 줘서 좋더라고요. 그리고 나중에 코드를 읽어 봤을때도 이해가 편한 것 같아요. 애초에 호출하는 쪽 처리 흐름에 맞게 method를 설계했으니까요. 그리고 생각하기에도 이 쪽이 더 편한 것 같아요. 구현부터 생각하면 처음부터 너무 많은 걸 생각해내야 해서 어렵더라고요. 도둑놈 심보로 시작하면 단순하게 생각할 수 있거든요 ㅋㅋ 그리고 각 메서드를 구현해나갈 때에도 이미 책임이 어느정도 분할되어 있기 때문에 각 책임 안에서만 생각하면 되어서 덜 복잡하고요!

[pythonstrup]

클라이언트 입장에서 한걸음씩 타고 내려간다 클라이언트는 인터페이스만 알지 그 안의 상세 구현은 모르는 상태다. 클라이언트 입장에서 필요한 게 모두 충족된 상태라면 다음 단계로 시점을 옮기자. 상태를 정의하고 상세 구현을 작성한다. 그리고 다시 시점을 옮긴다. 그렇게 한걸음씩 나아간다.

[pythonstrup]

TDD와 구현 프로세스가 비슷한 것 같다. 결국 테스트가 클라이언트의 입장이 되는 것이다.

• ATDD? => client side top-down 방식으로 TDD 진행
• 공부해보기