객체지향의 사실과 오해.. 그리고 TDA(Tell Don't Ask)

운좋게 F-LAB에서 진행하는 오프라인 스터디 모임에 참여할 기회가 생겼는데, '객체지향의 사실과 오해'를 읽고 요약한 내용을 발표하고 질문을 주고받으며, 배운 내용을 실무에 어떻게 적용하는지에 대한 사례를 짚어보는 과정으로 스터디를 진행했습니다.

 

이번 시간에는 5장 '책인과 메세지'에 대한 내용을 짚어보던 중 책임주도설계와 TDA(Tell Don't Ask)에 대해 배웠고 해당 내용을 복습하고자 이 게시글을 작성해가 되었습니다.

 

객체지향 프로그래밍에서 활용되는 원칙으로 'TDA 원칙'이라고도 합니다. 직역하자면 "묻지 말고 그냥 시켜라"가 되겠습니다.

이는 협력관계에 있는 객체끼리는 정보를 요구하지 말고 그냥 시키라는 의미로 해석할 수 있습니다. 정보를 요구하지 않는다는 점에서 '정보 은닉'의 중요성을 강조하는 원칙이기도 합니다.

'객체지향의 사실과 오해' 5장을 보면, '책임과 메시지'라는 용어가 나옵니다. 해당 내용을 서술하면서 객체의 자율적인 책임을 강조하며, 특정 객체가 가지고 있는 책임에 대한 기능을 요청을 받으면, 어떻게 해야 할지에 대한 책임은 스스로에게 주어져 있음을 강조하고 있습니다.

즉, 요청을 하는 객체는 해당 객체가 무엇을 할 수 있는지를 따로 묻지않고, 그저 특정 기능을 요청할 뿐이고, '그 요청을 수신한 객체가 그 기능을 수행할 수 있는지에 대한 책임의 유무를 자율적으로 판단한다'로 해석해 볼 수 있습니다.

이러한 문맥으로 봤을 때, 책임주도설계는 결국 TDA 원칙이 포함될 수도 있겠습니다.

그러나, 한가지 주의해야 할 점이 있습니다. TDA 원칙은 '정보 은닉'을 강조하지만 결코 캡슐화만을 강조하는 것이 아닙니다. 생성된 객체의 구체적인 타입을 숨기는 것이나 구현을 숨기는 것도 정보 은닉에 해당됩니다. 그래서 TDA 원칙을 엄격하게 지키려고 하는 개발자들은 getter 메서드 자체를 사용하지 않으려는 경향이 있는데, 이는 '객체의 자율적인 책임'을 앗아가는 행위가 될 수 있습니다. 그리고 경우에 따라 getter를 통해 객체 간의 비즈니스 로직을 단순화할 수 있는 경우도 종종 있을 수 있습니다. 마틴 플로어 역시 이점을 인지하고 있었고, 본인도 역시 TDA가 유용하다는 것을 알지만 GetterEradicators가 되지 않기 위해, TDA 원칙을 사용하려하지 않는다고 밝힌 바 있습니다.

결론

선배 개발자들이 남겨놓은 코드 및 개발 서적을 보면, 더 좋은 코드를 쓰기 위해 정해진 원칙들이 정말 많고 유용합니다. 그 원칙들을 인지하고 그대로 실현하려는 것은 정말 중요하고 어렵지만, 상황에 따라 응용하는 것은 더 어려운 듯합니다.

이러한 점에서 개발자는 기술적 지식만큼이나 중요한 것이 도메인의 요구사항을 구현하는 능력.. 즉, 커뮤니케이션이 중요하고 할 수 있겠습니다.

 

추가로 결제 도메인에 대한 관심이 커져, 외부 활동으로 우연히 알게된 프론트엔드 개발자분들과 협업을 하며, 사이드 프로젝트를 진행하고 있습니다.
아직 부족하지만 많은 관심 부탁드리겠습니다. :)
- https://github.com/payments-laboratory/payments-lab-api

 

출처

- https://martinfowler.com/bliki/TellDontAsk.html