인터페이스와 구현체 생성 순서

Spring Core Principles - Basics

Running and Testing a Member Domain

Written on

[질문 내용]
안녕하세요. 이미 로드맵 1회독을 마치고 TDD관련 공부를 하다가 객체지향과 DI,IoC의 개념에 대해 복기하기 위해서 강의를 듣던중 궁금한 부분이 생겨 질문을 남깁니다. 아직 개발 경력이 짧은 대학생임을 감안해주시면 감사하겠습니다.

인터페이스와 구현체를 분리하는 것의 중요성에 대해서는 잘 인지하였지만, 구현체를 작성하기 전 인터페이스를 먼저 작성하는 것에 대해서 의문이 생깁니다.

실제 몇몇 프로젝트 진행 경험 상으로, 파라미터나 메서드의 설계에 있어서 구현을 하면서 그 스펙이 변하는 경우가 매우 많았습니다. 그래서 구현을 먼저 하고 인터페이스를 그에 맞추어 생성하는 경우가 잦게 있었는데, 이런 경우에는 기능 설계가 충분하게 되지 않은 채로 개발에 시작한 잘못의 결과인가요? 실무 개발이나 프로젝트에서 인터페이스 개발 -> 구현체 개발 의 순서가 일반적인 경우일까요?

TDD관련한 개념에서도 인터페이스를 먼저 작성한 후 해당 메서드를 이용하여 TDD를 작성 -> 메서드의 기능이 검증 된 후에 구현을 하는 것으로 배웠습니다. 하지만 아무리 고민하여도 구현체를 먼저 작성하는 것이 개발 과정을 최적화하는 방법이라는 생각이 들어 질문 남깁니다.

정리하자면, 구현체 개발 후 인터페이스를 구현체에 맞게 작성하여 사용하는 방법이 잘못된 순서인지 여쭤보고 싶습니다.

spring객체지향

Answer 2

omg

안녕하세요. gdbs1107님, 공식 서포터즈 OMG입니다.

강의에서 설명한 할인정책 시나리오를 잘 생각해보시면, 궁금하신 부분이 일부 해소되실 것 같은데요,

처음에 할인 정책에 대한 요건을 받은 시나리오에서 할인의 요건이 (나중에 변경될 수 있다) 와

강의에서 설명하실 때 '기획자가 오픈 직전까지 고민을 미루고 싶다' 라는 요구사항을 받았습니다.

이러한 시나리오에선 구현체부터 작성하기 보다는 할인정책을 추상화해놓고, 변경에 유연하게 대응하는 즉, 인터페이스를 설계하는 것이 변경에 빠르게 대처가 가능할 것입니다.

만약, 할인 정책이 정액할인정책으로 픽스되고, 변경할 가능성이 없다면 굳이 추상화 할 필요는 없겠지요?

정리하자면, 인터페이스를 작성하는 것과 작성하지 않는 것은 개발하는 상황에 맞게 유연하게 가져가면 되고

추가로 말씀드리고 싶은것은 추상화 또한 비용이기에 추상화할 필요가 있는 상황을 잘 판단하여 인터페이스 설계를 고민해보면 좋을 것 같습니다.

AI 답변링크와 아래 영한님께서 설명하시는 인터페이스 추상화 관련 질문&답변도 참고해주세요 😀
https://www.inflearn.com/community/questions/69278

https://www.inflearn.com/community/questions/457629

감사합니다.

인프런 AI 인턴

안녕하세요, 인프런 AI 인턴입니다. gdbs1107님께서 질문하신 인터페이스와 구현체의 작성 순서에 대한 고민에 대해 답변드리겠습니다.

인터페이스와 구현체를 설계하고 개발하는 과정은 여러 가지 방법이 있으며, 각 프로젝트의 상황과 요구사항에 따라 다르게 적용될 수 있습니다. 일반적으로 인터페이스를 먼저 설계한 후 구현체를 개발하는 것은 다음과 같은 이유 때문입니다:

유연성과 확장성: 인터페이스를 먼저 설계하면 소프트웨어가 변경되거나 확장될 때 영향을 최소화할 수 있습니다. 구현과 비즈니스 로직이 인터페이스 뒤에 감춰져 있으면 변경이 용이합니다.
프로그래밍 관점 및 TDD: Test-Driven Development(TDD)에서는 테스트를 먼저 작성한 후 테스트를 통과하기 위한 최소한의 구현을 작성합니다. 이러한 접근은 인터페이스가 먼저 정의되어야 새로운 기능을 인터페이스에 따라 검증할 수 있습니다.

하지만 gdbs1107님께서 언급하신 것처럼, 구현을 진행하면서 인터페이스가 변하는 경우가 많다면 이는 일반적인 상황입니다. 실무에서는 인터페이스와 구현체 모두 함께 변화하고 진화할 수 있으며 다음과 같은 점을 고려하곤 합니다:

프로토타이핑과 피드백 루프: 초기 설계 단계에서 구현체가 먼저 나와야 인터페이스 설계가 명확해지는 경우도 있습니다. 이를 통해 필요한 기능과 스펙을 확인할 수 있습니다.
기능에 대한 명확한 요구사항 수립: 시작 전에 요구사항이 명확하다면 인터페이스를 먼저 작성하는 접근이 효과적일 수 있습니다. 하지만 요구사항이 모호하거나 진화하는 경우에는 구현체와 인터페이스를 같이 개발해 나가면서 피드백을 받을 수 있습니다.

실무에서도 클린 코드를 유지하고 설계를 깔끔히 다듬기 위해 인터페이스와 구현체를 병행하여 개발하는 방법을 자주 활용합니다. 따라서, 적절한 균형을 찾고 프로젝트의 요구사항에 맞게 접근하는 것이 중요합니다.

관련 질문과 예제에 대한 게시물을 함께 확인해 보세요:
- 실무에서 인터페이스 설계

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

Inflearn Community Q&A

인터페이스와 구현체 생성 순서