서비스 레이어 의존성역전의 장점은 보통 그 서비스 의존대상이 인터페이스이기 때문에 다중 extends가 가능한 점도 있고, 구현체의 정의를 내릴 때 최종 구현이 쉽기 때문에 그럼
choi4624(choi4624)2025-04-04 16:52
답글
그냥 Impl 찾아서 검색한 다음에 저 내용 달달외워서 똑같이 읊는 거지? 의존성 역전이 필요하면 그 때 인터페이스 만들면 되잖아 미래일을 어떻게 안다고 미리 만들어? 저게 그렇게 필수요소 같으면 커스텀 어노테이션으로 만들어놓고 자동적으로 인터페이스가 만들어지게 하면 되는 거 아님?
익명(211.200)2025-04-04 18:47
답글
ㄴ 커스텀 어노테이션 해볼 생각은 못했는데 함 해보고 나중에 기회되면 언급해봄 ㅋㅋ 근데 저러면 구 인터페이스 신 인터페이스 다 어노테이션으로 바꿔야 하겠네 어케 될지
choi4624(choi4624)2025-04-04 19:49
실용적으로 생각해보면 구현체가 두 개 이상이던가
조만간 구현체 두 개 이상 될 확률이 높을 때만 의미 있음
익명(211.234)2025-04-04 17:12
아는 만큼 보인다고 멍청했네 내 단계에선 쓸모없었지만 무의미한 건 아니구나
익명(117.111)2025-04-04 17:19
답글
무의미한거 맞다
구현체가 2개 이상 될때 그때 쪼개면 됨
미리 인터페이스 박아두는건 복잡도만 증가시킴 - dc App
익명(121.174)2025-04-04 17:39
답글
ㄴ 미리 쪼개자... 오늘도 이거 덕분에 코드 덜 뜯어고쳤어
choi4624(choi4624)2025-04-04 18:26
대부분은 쓸모없지
프로그래밍(nowadays3724)2025-04-04 17:38
통일하는게 편해서 그럼 그거 하나씩 만든다고해서 공수가 큰것도아님
나중에 그때가서 만들때 그게 공수가더 듦
그거 si들은 이유도 모르고 다 그런식으로 만들더라. 우리가 일반적으로 작성하는 서비스레이어는 인터페이스가 필여한 경우가 아니면 그럴필요 없지 - dc App
나중에 유지보수할때 결국 쓰게되는데 공부좀 더해라
https://velog.io/@jonghyun3668/%EB%AA%A8%EB%93%88-%EA%B3%84%EC%B8%B5%EA%B0%84-%EC%9D%98%EC%A1%B4%EC%84%B1-%EC%97%AD%EC%A0%84%EC%8B%9C%ED%82%A4%EA%B8%B0
처럼 레포지토리 단위에서 의존성 역전하듯이 서비스레이어에서도 의존성 역전을 사용하기 때문임.
서비스 레이어 의존성역전의 장점은 보통 그 서비스 의존대상이 인터페이스이기 때문에 다중 extends가 가능한 점도 있고, 구현체의 정의를 내릴 때 최종 구현이 쉽기 때문에 그럼
그냥 Impl 찾아서 검색한 다음에 저 내용 달달외워서 똑같이 읊는 거지? 의존성 역전이 필요하면 그 때 인터페이스 만들면 되잖아 미래일을 어떻게 안다고 미리 만들어? 저게 그렇게 필수요소 같으면 커스텀 어노테이션으로 만들어놓고 자동적으로 인터페이스가 만들어지게 하면 되는 거 아님?
ㄴ 커스텀 어노테이션 해볼 생각은 못했는데 함 해보고 나중에 기회되면 언급해봄 ㅋㅋ 근데 저러면 구 인터페이스 신 인터페이스 다 어노테이션으로 바꿔야 하겠네 어케 될지
실용적으로 생각해보면 구현체가 두 개 이상이던가 조만간 구현체 두 개 이상 될 확률이 높을 때만 의미 있음
아는 만큼 보인다고 멍청했네 내 단계에선 쓸모없었지만 무의미한 건 아니구나
무의미한거 맞다 구현체가 2개 이상 될때 그때 쪼개면 됨 미리 인터페이스 박아두는건 복잡도만 증가시킴 - dc App
ㄴ 미리 쪼개자... 오늘도 이거 덕분에 코드 덜 뜯어고쳤어
대부분은 쓸모없지
통일하는게 편해서 그럼 그거 하나씩 만든다고해서 공수가 큰것도아님 나중에 그때가서 만들때 그게 공수가더 듦