Spring Boot-Autowired 생성자의 목적은 무엇입니까?

저는 Spring Boot에서 1 년 넘게 개발했지만 Autowired 생성자의 이점을 아직 이해하지 못했습니다. 이것을 저에게 설명하고 모범 사례로 간주 될 것입니다.

다음과 같은 빈이 있다고 가정 해 봅시다.

@Component public class MyBean { void doSomeStuff() { } } 

그리고 저는 해당 빈에 대한 종속성이있는 서비스

@Service public class MyServiceImpl implements MyService { private MyBean myBean; } 

나에게이 클래스에 종속성을 주입하는 가장 간단한 방법은 단순히 @Autowired로 변수에 주석을 추가하는 것입니다.

@Service public class MyServiceImpl implements MyService { @Autowired private MyBean myBean; } 

그러나 다음과 같은 접근 방식을 선호하는 다른 온라인 사이트 (및 우리 팀의 다른 개발자)가 있습니다.

@Service public class MyServiceImpl implements MyService { private MyBean myBean; @Autowired public MyServiceImpl(MyBean myBean) { this.myBean = myBean; } } 

나에게 그런 생성자를 사용하는 것은 단순히 중복 코드입니다. 빈 자동 연결은 상용구 코드처럼 보이는 것보다 훨씬 간단하고 간단합니다.

코멘트

  • To me, using a constructor like that is simply redundant code. Autowiring the bean is much simpler and straightforward than what appears to me to be boilerplate code. private이고 setter가없는 instace 변수에 bean을 주입하는 마법에 대해 걱정하지 않습니까? 이것이 당신의 동료들에게 발생하는 엄청난 기술적 부채에 대해 걱정하지 않습니까? 설계 모범 사례 대신 Spring '의 매직 패러다임에 너무 많이 전달하는 것에 대해 걱정하지 않으십니까?
  • 다른 사용자가 인스턴스를 생성하도록 허용하는 것에 대해 걱정하지 않으십니까? 적절한 종속성 주입없이 MyServiceImpl을 사용할 수 있나요?
  • ' ' 아니요 " ", 제가 ' ' 이로 인해 엄청난 기술 부채가 어떻게 발생하는지 알지 못했습니다. ' 그토록 나쁜 습관에 대한 예를 제공 할 수 있다면 ' 감사합니다.
  • " 설계 우수 사례 대신 Spring '의 마법 패러다임을 너무 많이 전달하는 것에 대해 걱정하지 않으십니까? "이 토론과 관련하여 추천 할 수있는 좋은 설계 사례에 대한 리소스가 있습니까? '이 내용을 읽고 싶습니다.
  • 여기 참조 : stackoverflow.com/questions/34580033/ …

답변

개인 변수를 공개하는 대신 공개 getter 및 setter를 사용하는 것과 동일한 이유로 실제 생성자입니다.

실제 예 : 안전하고 정보에 민감한 물리적 위치에서는 휴대 전화를 사용할 수 없습니다. 보안 위치와의 모든 통신은 모니터링되지 않고 제어되지 않는 불량 통신 채널에 의해 은밀하게 이루어지지 않고 안전하게 설정되고 제어되고 암호화 된 통신 프로토콜을 통해 이루어져야합니다.

콘서트에서는 사람들이 그렇게하는 것을 허용하지 않습니다. 이미 경기장에있는 사람에게 울타리 너머로 물건을 던지십시오. 들어오고 나가는 모든 것은 게이트를 통과해야합니다.

코드 예제가 그게 전부라면 불필요하게 장황한 상용구처럼 보입니다.하지만 생성자에서 설정 외에 다른 작업을 수행하는 경우가 많습니다. 유효성 검사와 같은 비공개 변수입니다. 많은 프로그래밍 언어에서이 작업을 수행하는 방식을 변경하는 것은 이진 브레이킹 변경입니다. 따라서 생성자를 미리 제공하는 것이 현명한 단계가 될 수 있습니다.

마지막으로 클래스는 종속성 주입과 독립적으로 작동 할 수 있어야합니다. private 멤버에 주석을 추가했지만 생성자를 포함하지 못한 경우 , 기본적으로 해당 클래스를 DI 컨테이너에 단단히 바인딩했으며 클래스가 없으면 작동하지 않습니다.

댓글

  • " 콘서트에서 ' 사람들이 울타리 너머로 물건을 던지는 사람에게 '는 이미 stadiu에 있습니다. 미디엄. 들어오고 나가는 모든 것은 게이트를 통과해야합니다. "하지만 생성자를 사용하면 자동 연결이 어떻게 더 안전 해지는 지 ' 알 수 없습니다. 생성자 요구 사항 (예 : 유효성 검사)이 없다면 생성자를 사용하는 것이 유익할까요?
  • 바이너리 호환성을 깨지 않고 나중에 유효성 검사를 추가 할 수 있습니다.
  • 또한 , 비공개 회원 은 실제로 비공개 상태를 유지해야합니다. '는 비공개 회원을 갖는 전체적인 요점입니다.
  • 요점은 @Autowire와 호환되는 설계 우수 사례를 허용하는 것입니다. 생성자를 갖는 것은 OOP에서 가장 자연스러운 것입니다. 반대로, (당신이 간단하고 간단하다고 부르는) 좀 무섭습니다. 생성자를 제거해도 실제 이점은 없으며 ' 전혀 단순하지 않습니다. 생성자는 OOP에서 가장 간단한 방법 중 하나입니다.그 자체로 일반적으로 Spring IoC의 마법을 구현할 가치가있는 복잡성이 거의 없습니다.
  • '의 가치에 대해 Java는 어쨌든 아주 장황한 언어입니다. ' 그 장황함 중 일부를 길들이려는 경우 생성자를 제거해도 움푹 들어간 곳이 많지 않습니다.

답글 남기기

이메일 주소를 발행하지 않을 것입니다. 필수 항목은 *(으)로 표시합니다