equals - 구현(2)에서 자동 완성으로 코드 한줄이 없이 나오는데 제가 생각한게 맞나요?

안녕하세요. 박혁진님저도 궁금해서 찾아보니 다음 이슈로 패치되었네요 🙂https://youtrack.jetbrains.com/issue/IDEA-357686 다음 내용으로 메뉴얼에도 반영해둘게요 🙂 > 참고: 최신 IntellJ에서는 equals 구현에서 다음 첫 줄 코드가 제거된다.if (this == o) return true;* 이유: 내부 분석 결과, 대부분의 실무 코드에서는 자기 자신을 비교하는 경우가 거의 없다. 따라서 분기 예측 미스가 더 큰 비용을 유발한다는 리포트(IDEA-357686)가 반영되었다.감사합니다.

OrderServiceImpl 클래스에 의존성 주입이 되는 이유를 모르겠습니다

안녕하세요. yoon6669님이번 테스트 코드에서는 스프링 컨테이너를 사용하지 않기 때문입니다.// 이 코드는 순수 자바 코드입니다 (스프링 컨테이너 없음) OrderService orderService = new OrderServiceImpl(new MemoryRepository(), new FixDiscountPolicy()); 여기서 중요한 포인트들을 정리해보겠습니다:1. 테스트 코드의 특징이 테스트는 순수 자바 테스트입니다스프링 컨테이너(@SpringBootTest, ApplicationContext 등)를 사용하지 않습니다따라서 @Component, @Autowired 같은 스프링 어노테이션이 전혀 동작하지 않습니다2. 왜 오류가 나지 않는가?@Autowired는 스프링 컨테이너가 객체를 생성할 때만 동작합니다테스트에서는 new OrderServiceImpl(...)로 직접 객체를 생성하고 있습니다생성자에 직접 파라미터를 전달하므로 의존관계가 수동으로 주입됩니다스프링 컨테이너가 개입하지 않으므로 빈 등록 여부는 상관없습니다4. 스프링 컨테이너를 사용한다면?만약 스프링 컨테이너를 사용하는 테스트라면:@SpringBootTest class OrderServiceTest { @Autowired OrderService orderService; // 이 경우 FixDiscountPolicy가 빈으로 등록되어야 함 } 결론: 테스트 코드는 순수 자바이므로 스프링의 자동 주입 메커니즘과는 별개로 동작합니다. 직접 객체를 생성하고 생성자로 의존관계를 주입하는 것입니다. 감사합니다.

Test코드는 통과하는데 CoreApplication 에러가 난다면

안녕하세요. yoon6669님 🙂강의에서 사용하는 TEST는 모든 테스트를 정확하게 만족하는 TEST 케이스를 만드는 것이 목적이라기 보다는 학습을 목적으로 TEST를 사용하는 것으로 이해하시면 됩니다.물론 학습이 목적이 아니라 실제 애플리케이션을 만든다면 모두 통과하는 정확한 테스트를 해야겠지요?감사합니다.

강의 자료

dbaldpahd0216님 감사합니다 🙂다음 패치에 반영하겠습니다^^!

부모타입도 빈에 등록 되나요?

안녕하세요. yoon6669님문의하신 내용은 스프링 컨테이너가 빈을 조회하는 방식과 자바의 객체 타입 시스템(상속 및 인터페이스 구현)이 결합되어 나타나는 동작입니다.스프링 빈의 등록과 타입:스프링 컨테이너는 @Configuration 애노테이션이 붙은 설정 클래스에 정의된 @Bean 메서드를 호출하여 스프링 빈을 등록합니다.@Bean 메서드의 반환 타입이 해당 스프링 빈의 타입이 됩니다.예를 들어, TestConfig 클래스에서 rateDiscountPolicy() 메서드는 RateDiscountPolicy 객체를 반환하고 fixDiscountPolicy() 메서드는 FixDiscountPolicy 객체를 반환합니다. 따라서 RateDiscountPolicy와 FixDiscountPolicy의 인스턴스가 스프링 빈으로 등록됩니다.빈 조회 시 타입 매칭:스프링 컨테이너에서 ac.getBean(타입)이나 ac.getBeansOfType(타입)과 같이 타입으로 빈을 조회할 때, 스프링은 컨테이너에 등록된 빈들 중에서 요청한 타입과 호환되는 (assignable) 타입의 빈들을 모두 찾습니다.여기서 '호환된다'는 것은 요청한 타입이 등록된 빈의 실제 클래스의 부모 클래스이거나, 등록된 빈의 실제 클래스가 요청한 인터페이스를 구현한 경우 등을 포함합니다. 즉, 자바의 다형성이 적용됩니다. 부모 타입으로 조회하면 자식 타입도 함께 조회되는 것이 바로 이 때문입니다.DiscountPolicy.class로 조회 시:TestConfig에서는 RateDiscountPolicy 빈과 FixDiscountPolicy 빈이 등록되었습니다.RateDiscountPolicy 클래스와 FixDiscountPolicy 클래스는 모두 DiscountPolicy 인터페이스를 구현하고 있습니다 (소스 코드 상에는 직접적으로 구현 코드가 보이지 않지만, 맥락상 그렇다고 가정할 수 있습니다. 예:의 DiscountPolicy 인터페이스와의 RateDiscountPolicy 구현체).따라서 ac.getBeansOfType(DiscountPolicy.class)를 호출하면, 스프링은 DiscountPolicy 타입 또는 그 하위 타입(구현체)의 빈을 찾습니다. RateDiscountPolicy와 FixDiscountPolicy는 DiscountPolicy의 구현체이므로, 이 두 빈이 조회되는 것입니다. DiscountPolicy 자체는 추상화된 인터페이스일 뿐, 그 자체로 인스턴스화되어 빈으로 등록된 것은 아닙니다. 하지만 그 구현체들이 DiscountPolicy 타입으로 "호환"되기 때문에 조회 대상이 됩니다.Object.class로 조회 시:자바의 모든 클래스는 Object 클래스를 상속받습니다. Object는 모든 자바 객체의 최고 부모입니다.스프링 컨테이너에 등록된 모든 빈은 어떤 클래스의 인스턴스이든 결국 Object 타입을 상속받고 있습니다.따라서 ac.getBeansOfType(Object.class)를 호출하면, 스프링은 Object 타입 또는 그 하위 타입의 빈을 찾게 되는데, 이는 스프링 컨테이너에 등록된 모든 빈에 해당됩니다.요약하자면, DiscountPolicy나 Object 클래스 자체가 빈으로 등록된 것이 아니라, 해당 인터페이스를 구현했거나 해당 클래스를 상속받은 자식 타입(구현체)의 빈들이 등록되어 있고, 스프링이 타입을 통해 빈을 조회할 때 요청된 타입과 호환되는 모든 빈을 반환하기 때문에 이러한 동작이 나타나는 것입니다.추가로 자바는 instanceof, Class.isAssignableFrom 등의 기능을 통해서 다른 타입이 본인의 자식 타입인지 아닌지 인지할 수 있습니다.감사합니다.

답변부탁드리겠습니다.

안녕하세요. 임다정님다음 링크를 참고해주세요 🙂https://inf.run/SLoBz 감사합니다.

엔티티 직접 사용 - 외래키값 지연로딩

안녕하세요. Wendy Wendy님그렇지 않습니다. where 같은 필터링 조건은 즉시로딩에 영향을 주지 않고, 오직 조회 대상인 select 절에서만 즉시 로딩이 영향을 받습니다.감사합니다.

퀴즈 중복 정답 가능 여부 질문 드립니다.

안녕하세요. 조재영님생각하신 내용이 맞습니다.AI 퀴즈에 문제가 있네요 🙂관련해서 인프런에 전달 드릴게요 🙂감사합니다.

querydsl 빌드 문제 질문드립니다.

안녕하세요. 6udguin님스프링 부트 3.x를 사용중이시군요 🙂강의 메뉴얼에 있는 다음 내용을 참고해주세요.> 참고: 스프링 최신 버전에서는 Querydsl 설정이 달라진다. Querydsl 설정이 잘 안된다면 다음을 참고하자. 스프링 부트 2.x, 3.x 모두 참고할 수 있다.> https://bit.ly/springboot3 직접 링크https://docs.google.com/document/d/1j0jcJ9EoXMGzwAA2H0b9TOvRtpwlxI5Dtn3sRtuXQas/edit?tab=t.0#heading=h.iayahq64el0u감사합니다.

ItemUpdateForm의 필드 quantity에 @NotNull이 없는이유

안녕하세요. 만달라님이 예제에서는 수량의 경우 빈 값도 넣을 수 있도록 허용해두었습니다.특별한 이유가 있는 것은 아니고, 이 예제에서는 비즈니스 상황에 따라서 수량이 0일 수도 있지만, 이 경우 수량 자체를 아직 설정하지 않았다는 의미로 보시면 됩니다.감사합니다.