Home Service 구현체를 추상화 하는것에 대해
Post
Cancel

Service 구현체를 추상화 하는것에 대해

Service 구현체를 추상화 하는것에 대해..

🎊 시작하기 전에..

초보 개발자인 저의 의견에 대해 정리한 글입니다.

interface-구현체구조를 흔히 무지성, 즉 이유없이 사용하거나 관례라서 사용하는 사례을 많이 봐왔습니다. 저는 그것을 굳이 interface를 사용해야 하는가? 라는 생각이 들어 글을 적었습니다.

✨ 다형성

Service의 구현체를 interface로 추상화해서 사용하는 이유중 가장 큰 이유가 다형성일 것입니다.

다형성이란 간단하게 하나의 Type에 여러 객체를 대입할 수 있는 성질입니다. 하지만 일반적인 스프링에서 서비스의 다형성을 굳이 구현해야 하는 이유를 저는 찾지 못했습니다.

예를 들어, UserService를 구현할 때 기능으로 유저 정보 가져오기, 닉네임 변경 등이 있다고 가정합시다. 이 UserService의 구현체가 여러 개 생길상황이 아닌데도 이유없이 interface-구현체구조를 사용하는 것이 예시로 있습니다.

따라서 저는 interface를 사용하지 않고, 서비스를 설계할 때 도메인별 서비스 분리를 더 집중해서 하나의 도메인에 여러개의 서비스가 생기지 않게 설계를 하는것이 좋을 것 같다고 생각합니다.

🚩 정리

따라서 저는 Service의 interface를 두지 않고 개발을 하다가, 유연함과 확장성이 필요할 때 인터페이스를 사용하는 방법이 적절하다고 생각합니다.

구조를 정하는데 정답은 없다고 생각합니다. 제가 말한 방법또한 상황에 따라 맞는 구조일수도, 잘못된 구조일수도 있다고 생각합니다.

저와 다른 생각을 가지신분들의 의견 환영합니다❤

부족한 글이지만 읽어주셔서 감사합니다😁😁

This post is licensed under CC BY 4.0 by the author.