묻고 답해요
141만명의 커뮤니티!! 함께 토론해봐요.
인프런 TOP Writers
-
미해결스프링 핵심 원리 - 기본편
싱글톤패턴 DIP 위반
[질문 내용]싱글톤 패턴 문제점에서 getInstance() 사용시 DIP를 위반한다고 하신 점이 이해가 잘 안가서 직접 구현해보았습니다. 제가 이해한 내용이 맞나요...? [구현 내용]싱글톤 객체의 의존성 주입에 관한 문제이므로, SingletonService에 주입한 SingletonRepository를 생성하였습니다.public class SingletonRepository { private static final SingletonRepository instance = new SingletonRepository(); public static SingletonRepository getInstance() { return instance; } private SingletonRepository(){} } SingletonService에 SingletonRepository 필드를 추가합니다.public class SingletonService { private SingletonRepository singletonRepository; ... }DIP를 지키기 위해선, DI를 해야합니다. 하지만 SingletonService에 의존관계를 주입할 수 있는 방법이 없습니다...생성자 주입 방법: 추가 객체 생성을 막기 위해 생성자를 막아놓았으므로 불가.필드 주입, setter 주입, 일반 메서드 주입: 스프링 기술, 순수 자바 코드로 주입 불가.클라이언트코드인 SingletonService가 SingletonRepository를 사용하기 위해 다음과 같이 구현체에 의존해야 합니다. public class SingletonService { private SingletonRepository singletonRepository = SingletonRepository.getInstance(); ... }따라서 순수 자바 코드로 싱글톤 패턴 구현 시 DIP를 위반합니다.
-
미해결스프링 핵심 원리 - 기본편
의존관계 주입 타이밍과 setUrl() 불러오는 타이밍
안녕하세요. NetworkConfig에서 객체를 생성한 후 setUrl()이 불리는데 의존관계 주입과 setUrl()을 부르는 타이밍? 순서를 알수 있을까요? 무조건 setUrl()을 부른뒤에 의존관계가 주입되나요?
-
미해결스프링 핵심 원리 - 기본편
Service 구현체와 DIP
DIP를 지키려면 클라이언트는 구현 클래스가 아닌 인터페이스에 의존해야 하는 것으로 알고 있습니다. 때문에 프로젝트에서 컨트롤러는 구현체가 아닌 인터페이스를 호출해서 인터페이스의 기능을 사용하고 서비스 레이어에서 구현 객체를 만드는 식으로 프로젝트를 진행했습니다. 프로젝트를 얼추 마무리하고 리뷰하는 과정에서 인터페이스에 대해 재고하게 되었고 이 과정에서 '기능의 확장 가능성이 없는 메서드까지 추상화를 해야 하나?' 라는 의문이 들었습니다. 인터페이스는 자바의 다형성을 살려 기능의 확장의 필요한 순간 새로운 구현체로 기능을 확장하는데 의의가 있다고 생각하는데 기능의 확장이 필요하지 않을 때는 인터페이스로 굳이 추상화 과정이 필요없다는 생각이 들었습니다. 근데 이렇게 프로그램을 리팩토링하게되면 DIP가 깨진다는 생각이 들었습니다. 결국 추상화를 하지 않는다는 것은 컨트롤러에서 직접 구현 클래스를 가져온다는 것인데 이건 인터페이스를 의존하는 것이 아니기 때문입니다. 때문에 추상화가 필요없으면 구태여 하지 않는 방향이 좋은 것인지 DIP를 깨지 않기 위해 의미없는 추상화라도 필요한 것인지 궁금합니다.
-
미해결객체 지향 프로그래밍 입문
DIP 관련해서 궁금한게 있습니다.
DIP 예제의 답을 보기 전 제가 생각한 상위 정책은 상세 정보를 추출하는 기능, API를 호출하는 기능, 상품을 구하는 기능으로 나눠서 생각했습니다. 정보 추출과 상품을 구하는 기능은 유사했지만 Daara API를 통해 상품을 구하는 기능은 하위 모듈로 분류되어 있었서 질문을 하게 되었습니다. API 호출 또한 추후 다른 API를 통해 상품을 구한다고 가정하면 API 호출 또한 상위 수준의 정책으로 볼 수 있지 않나 라고 생각을 했습니다. 하지만 범균님 분류를 보니까 API 호출이라는 구현 방식(하위 관점)에서 생각한 접근 방법이라고도 생각을 하게 되네요... API 호출을 상위 모듈로 분류한 것은 하위 관점(구현 관점)에서 추상화를 진행한 것인지 궁금합니다.
-
미해결스프링 핵심 원리 - 기본편
3분쯤..
@Autowiredpublic OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) { this.memberRepository = memberRepository; this.discountPolicy = discountPolicy;} 여기서 discountPolicy => rateDiscountPolicy this.discountPolicy = discountPolicy; 이거를 this.discountPolicy = rateDiscountPolicy; 이렇게 쓴 이유는 DIP를 위배하지만 어쩔수없는 선택인가요? 그리고 제가 강의를 쭉 듣고있는데 클린코드를 확실하게 100%지키기는 것은 힘드니까 최대한 맞춰서 설계하는 건가요?
-
미해결스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술
의존성 외부주입 관련 질문입니다!.
안녕하세요!. 강의 막바지에 해당 프론트 컨트롤러에 등록되는 핸들러 매핑 맵과, 핸들러어댑터 콜렉션에 대해서 외부에서 주입하도록 해봐도 된다고 하셨는데, 스프링을 사용할때는 @Configuration과 @Bean 애노테이션을 사용해 Config 클래스에서 의존성을 입맛에 맞게 주입할 수 있었는데, 지금과 같이 스프링을 안쓰고 주입을 하려면 어떻게 해야 할지 키워드가 있을까요? 프로젝트 구동시 어느 시점에서 서블릿이 스캔되서 등록되는지 몰라서 어디에 해당 정보들을 setter든 생성자든 주입해야할지 모르겠습니다 ㅠ