Beverage 인터페이스
테스트의 질문과는 좀 벗어나는 질문입니다만.. 궁금해서 여쭤보게 되었습니다!
간단한 프로젝트를 구성하는 과정에서 Beverage라는 인터페이스를 만들어 추상화를 진행하고 해당 인터페이스는 get의 행위만 가지고 있었습니다.
그리고 추가된 라떼와 아메리카노 둘 다 같은 속성이지만 구현을 통해서 두 개의 구성 클래스를 만들어 예제를 진행하였는데요.
이에 다음과 같은 의문점이 생겼습니다.
인터페이스가 get이라는 행위만 가져도 사용해도 괜찮은지.
지금과 같은 상황에서는 확장에서의 의미로 추상 클래스가 더 괜찮을 것 같은데 사용하지 않은 이유가 있으신지 궁금합니다ㅎㅎ
좋은 강의 제공해주셔서 감사합니다~
답변 2
1
안녕하세요, 종운 님! :)
인터페이스가 get이라는 행위만 가져도 사용해도 괜찮은지.
인터페이스 설계에 정답은 없습니다.
추상화 과정을 통해서 의미를 부여할 수만 있다면 얼마든지 가능한 것이 아닐까요? ㅎㅎ
지금과 같은 상황에서는 확장에서의 의미로 추상 클래스가 더 괜찮을 것 같은데 사용하지 않은 이유가 있으신지 궁금합니다ㅎㅎ
저는 기본적으로 인터페이스와 추상 클래스 중에서는 인터페이스를 선적용하는 편입니다.
추상 클래스는 상속 기반 구조여서 인터페이스보다 유연성이 떨어지기 때문입니다.
답변이 되셨기를 바랍니다.
감사합니다. :)
0
안녕하세요, 인프런 AI 인턴이에요. Beverage 인터페이스와 추상화에 대한 의문을 갖고 계시군요.
인터페이스가 get이라는 행위만 가지고 있어도 사용하더라도 괜찮은지, 추상 클래스를 사용하지 않은 이유에 대해 궁금하신 것 같아요.
인터페이스는 클래스들 간의 공통 메서드를 정의하고, 이를 구현한 클래스들은 각자의 방식으로 구현할 수 있도록 돕는 역할을 해요. 따라서, Beverage 인터페이스가 get이라는 행위만을 가지고 있다면, 이는 다른 클래스들이 해당 행위를 구현할 때 필요한 최소한의 메서드를 정의하는 것이라고 할 수 있어요.
추상 클래스는 인터페이스와 달리 메서드의 일부 구현을 가질 수 있습니다. 따라서, Beverage 인터페이스 대신 추상 클래스를 사용해도 동일한 기능을 구현할 수 있지만, 인터페이스를 사용하는 것이 더 많은 유연성을 제공한다고 볼 수 있어요. 예를 들어, 추후에 Beverage 클래스 외에 다른 클래스를 더 추가하고자 할 때, 인터페이스를 사용하면 더 쉽게 확장할 수 있습니다.
따라서, 지금과 같은 상황에서 인터페이스를 사용한 것은 인터페이스의 확장성과 유연성을 고려한 선택이었을 것으로 생각됩니다. 추상 클래스를 사용하지 않은 이유는 확장성과 유연성을 높이기 위해서일 수도 있습니다.
더 궁금한 점이 있으시다면 언제든지 질문해주세요. 좋은 강의를 받으셨다니 저도 기쁘네요. 감사합니다~요.
private 상수 테스트 관련 질문
0
82
1
void는 어떻게 테스트하나요..? void로 애초에 코딩하면 안되나요??
0
123
2
커버리지는 어떻게 활용하시는지 궁금합니다.
0
158
2
테스트 문서화 질문입니다
0
104
2
단위테스트 질문이 있습니다
0
93
2
컨트롤러는 모킹을 한 이유가 궁금합니다.
0
100
2
ERD 가장자리에 있는 도메인 테스트 질문
0
86
2
DTO 검증 필드에 대한 테스트 코드 작성은 어디까지?
0
131
2
OrderCreateRequest DTO에 대해서 궁금한점
0
101
2
고전파의 테스트 대역 사용 대상, 공유 의존성
0
153
2
계층 관련 질문이 있습니다.
0
137
3
'코틀린'에서는 빌더를 따로 쓰지 않는데, 이 때는 어떻게 test fixture를 만드시는지 궁금합니다
1
122
2
혹시 update 로직은 어떻게 테스트하나요? (@Setter?)
0
133
2
단위테스트와 통합테스트의 경계가 궁금합니다.
0
224
2
Service+Repository 통합테스트 관련 질문입니다.
0
149
2
OrderControllerDocsTest 작성 해봤는데요. 날짜 형식이 이상하게 나와요
0
183
2
test 용 .yml
0
89
2
throws Exception
0
78
2
카페키오스크 클래스 문의 ,,
0
87
2
Rest docs 문서용 테스트코드를 따로 작성해야 되나요?
0
171
2
테스트 코드에서 필요한 생성자
0
136
1
tearDown 순서
0
114
2
@Builder 생성자 private
0
133
2
@DisplayName gradle / intellJ
0
91
2





