Closed pythonstrup closed 1 month ago
저는 지금까지 객체지향을 고려하지 않고 코드작성을 해왔어서 위에서부터 필드, 메서드 순으로 쭉 작성했던 것 같아요. 하지만, 메서드 부터 작성한다고 상상했을 때 장점을 생각해본다면 내가 설계한 흐름을 한번 더 따라가면서 설계를 복습>? 한다는 느낌이 드네요. 그러면서 메세지의 흐름이 논리적으로 이상하다거나, 생각지 못한 필드를 추가할 수 도 있을 것 같아요.
저는 보통 메서드 먼저 정의해요. 흔히 top-down이라고 말하는 순서대로 구현하는 편입니다. client쪽의 흐름부터 작성하는데, 이 때는 수신할 객체가 어떻게 구현할 수 있을지는 고려하지 않아요. 수신할 객체가 갖고 있지 않은 메서드라도 일단 메시지와 client가 넘겨줄 수 있는 parameter, 돌려받을 return type 먼저 쭉 써봐요(이거 줄테니까 저거 내놓으라는 도둑놈 심보로 일단 작성합니다). 호출할 메서드에 대한 구현은 그 다음에 해요.
이렇게 하면 수신 객체의 내부 사정이 client쪽에 영향을 좀 덜 줘서 좋더라고요. 그리고 나중에 코드를 읽어 봤을때도 이해가 편한 것 같아요. 애초에 호출하는 쪽 처리 흐름에 맞게 method를 설계했으니까요. 그리고 생각하기에도 이 쪽이 더 편한 것 같아요. 구현부터 생각하면 처음부터 너무 많은 걸 생각해내야 해서 어렵더라고요. 도둑놈 심보로 시작하면 단순하게 생각할 수 있거든요 ㅋㅋ 그리고 각 메서드를 구현해나갈 때에도 이미 책임이 어느정도 분할되어 있기 때문에 각 책임 안에서만 생각하면 되어서 덜 복잡하고요!
클라이언트 입장에서 한걸음씩 타고 내려간다 클라이언트는 인터페이스만 알지 그 안의 상세 구현은 모르는 상태다. 클라이언트 입장에서 필요한 게 모두 충족된 상태라면 다음 단계로 시점을 옮기자. 상태를 정의하고 상세 구현을 작성한다. 그리고 다시 시점을 옮긴다. 그렇게 한걸음씩 나아간다.
TDD와 구현 프로세스가 비슷한 것 같다. 결국 테스트가 클라이언트의 입장이 되는 것이다.
내용
질문