[Chapter03] 추상적인 관점의 설계가 좋다고 하는데, 왜 애매할 땐 객체로 시작하라고 할까요?

[YJGwon]

추상적인 관점에서 협력을 바라보는 것이 선행되어야 유연한 설계를 할 수 있다는 말에 엄청 공감했어요. 그런데 "객체 대 역할" 장에서 책임 수행을 여러 객체가 할 지 아닐지 모호하다면 일단 객체로 간주하고 시작하라고 권하더라고요. 역할인지 객체인지 초기에 중요하지 않다는 건 알지만, 한 가지로 간주해야 한다면 왜 추상적인 역할이 아닌 객체일까 궁금해졌습니다. 모호하다면 오히려 추상적으로 남겨두고 나중에 객체를 정의해도 되지 않을까요? 저자는 왜 객체로 간주하길 권했을까요?

제 생각엔, 구현의 관점에서 풀어본다면 "처음부터 인터페이스를 다 정의하지 말고 애매하면 객체로 두고 나중에 협력의 공통적 부분이 드러나면 그 때 인터페이스를 분리하라" 라는 뜻으로 해석할 수도 있을 것 같긴 해요. 그런데 이 장은 구현에 앞서 설계 관점에서 이야기 하는 장이라고 이해해서 더 혼란스러워요 😭

[JisuPark-dev]

흥미로운데요. 적절한 예시인지 모르겠지만, 개념적으로 생각해봤을 때 sudong을 sudong아빠라고 부르지 않는 것과 같지 않을까 생각해봤습니다. 제가 sudong이면서 아빠일 수도 있기 때문에 미리 sudong 아빠~라고 부른다면 좀 어색하지 않을까요? 저는 지금은 sudong이니깐, sudong으로 부르고, 나중에 애기가 생기면 sudong 아빠라고 부르는게 맞을 것 같아요.

마찬가지로 객체일까 추상적인 역할일까 판단하는 것도, 현상태가 객체이기 때문에 미리 예상해서 추상적인 역할로 부른다면 그게 이상할 것 같다? 고 생각이 들었습니다.

[JisuPark-dev]

조용호님의 답변은 '우리의 개념은 불완전하기 때문에 처음부터 완벽하게 알 수 없다(특히 소프트웨어는 현실세계를 그대로 반영한 것이 아니기 때문에) + 책임과 협력의 큰 그림을 탐색하는게 중요하므로, 애매하다면 객체로 시작해서 후에 정제과정을 거쳐라'라고 말씀하시네요!

개인적으로는 현실세계를 그대로 반영한 것이 아니라는 점에서 기인한 불완전성 때문에 애매함을 느낄 수 있다고 생각이 들었습니다.