TDD를 하면서 항상 의존성의 제일 하단에 있는 클래스 먼저 테스트를 했었다
그 이유는 의존하는게 없는 가장 구현하기 간단한 녀석이었기 때문이다
하지만 사다리 타기 게임을 하면서 느낀 것은 핵심 비즈니스 로직을 먼저 구현하는게 더 나을 수도 있겠다 다는 것이었다
사다리 한점을 나타내기 위해 Point 라는 객체를 놓고 그 위에 두 점을 이은 Line 이라는 클래스와 Line들로 이루어진 Ladder를 생성하였다. 하지만 만들면서 느끼점은 각각의 상위의 의존성으로 올라갈 수록 의존하고 있는 객체의 데이터를 자꾸 의식한다는 것이었다.
모름지기 객체의 응집도를 높히고 결합도를 낮추려면 책임주도개발 (일단은) 최고라고 생각한다
객체의 일괄된 행동에 따라 클래스를 작성하게 되면 그 행위들을 하나의 일괄적인 응집도를 가지게 된다.
반대로 데이터에 따라 개발하게 된다면 데이터에 행동이 어떻든 간에 주먹구구식으로 객체를 이어나갈 수 밖에 없다
핵심 비즈니스 로직을 짜는데 저 멀리있는 Point라는 객체의 데이터에 정신이 팔려서 90%의 프로그래머의 얼굴로 하루를 보냈다
어짜피 input과 output만 알면 핵심 로직을 테스트할 수 있으니, 세부적인 의존도들은 그때그때 리팩토링해가면서 만들 수 있다. 세부 의존성은 데이터를 잘 알고있는 객체한테 시키면 된다. 객체 만들고 시켜라. 너가 지금 작업하는 객체는 하나밖에 관심없는 게으르고 이기적인 녀석이다.
계속 BottonUp 방식으로만 연습을 하려고했는데 그게 독이 된 것 같다. 핵심 로직이 복잡하다면 TopDown 방식으로 개발하고 리펙토링 사이클을 짧게 가져 가는게 좋겠다
