SPRING

SOLIDSRP - 단일 책임 원리OCP - 개방 -폐쇄 원칙LSP - 리스코프 치환 원칙 ISP - 인터페이스 분리 원칙DIP - 의존 관계 역전 원칙(Single Responsibility Principle) 📌 한 클래스는 하나의 책임만 가져야 한다중요한 기준은

주문 서비스 클라이언트 (OrderServiceImpl) 는 DiscountPolicy 인터페이스에 의존하면서 DIP 를 지켰는데 \- 클래스 의존관계를 분석 -> 추상(인터페이스) 뿐 아니라 구체(구현) 클래스에도 의존 추상(Interface) : DiscountP

ApplicationContext를 스프링 컨테이너라 한다ApplicationContext는 인터페이스스프링을 생성할 때는 구성정보를 지정해주어야 한다 , AppConfig.class 를 구성정보로 지정빈 이름은 메서드 이름을 사용빈 이름을 직접 부여 가능📌 주의 :

🤔 스프링은 태생이 기업용 온라인 서비스 기술 지원을 위해 탄생웹 애플리케이션은 보통 동시에 여러 요청을 한다고객 트랙픽이 많으면 메모리 낭비 가 심하다해결방안 📌 해당 객체가 딱 1개만 생성되고, 공유하도록 설계 하면 된다이것을 싱글톤패턴이라 함클래스의 인스턴스가

수백개의 빈이 일일이 등록하기 번거로움, 설정 정보가 커지고, 누락하는 문제 발생 하는 등 문제가 생길 수 있다📌 컴포넌트 스캔: 스프링이 설정 정보가 없어도 자동으로 스프링 빈으로 등록해주는 기능 제공의존관계도 자동으로 주입하는 @Autowired 라는 기능도 제

@Configuration 클래스는 스프링 애플리케이션 컨텍스트에 빈으로 등록될 수 있으며, @Bean 어노테이션이 적용된 메서드를 통해 빈을 생성할 수 있습니다.@Bean 메서드에서 의존주입을 할 수 있는 방법에는 다음과 같은 형태가 있습니다.@Autowired 어노

생성자 주입수정자 주입 (setter 주입)필드 주입일반 메서드 주입생성자를 통해서 의존 관계를 주입 받는 방법특징 생성자 호출시점에 딱 1번만 호출 되는 것을 보장불변, 필수 의존 관계에 사용🚨 중요! 생성자가 딱 1개만 있으면 @Autowried 를 생략해도 자동

최근 스프링을 포함한 DI 프레임워크 대부분이 생성자 주입을 권장한다. 대부분의 의존관계 주입은 한번 일어나면 애플리케이션 종료시점까지 의존관계를 변경할 일이 없다오히려 대부분의 의존관계는 애플리케이션 종료 전까지 변하면 안됨수정자 주입을 사용하면 setter 메서드를

@Getter @Setter 를 이용해 코드를 줄여줌📌 @RequiredArgsConstructor 기능을 사용하면 final 이 붙은 필드를 모아서 생성자를 자동으로 만들어 준다 이 게시글은 인프런 김영한님의 스프링 강의를 정리한 글입니다.

@Autowired 는 타입(Type) 으로 조회된다.타입으로 조회하기 때문에 밑의 코드와 유사하게 동작한다DiscountPolicy 의 하위 타입이 2개가 스프링 빈으로 등록 되어 있다면NoUniqueBeanDefinitionException 오류 발생!!!해결 방법

오래된 기술이나 아키텍처를 사용하여 개발되었거나, 현재의 개발 표준이나 기술적 요구사항을 충족시키지 못하는 소프트웨어 프로젝트를 의미레거시 프로젝트는 유지보수와 업그레이드에 많은 비용과 시간이 소요새로운 기술과 아키텍처를 도입하여 프로젝트를 재설계하거나 대체하는것이 일

생성시 Use getters during code generation 선택해주는게 좋음선택하지 않으면 직접 필드로 접근하고 체크시 getter로 접근하는데직접 필드 접근시 프록시로 접근할 때는 접근을 할 수 없다!!

build.gradle 에서 디펜던시 안에 넣어주면 끝📌 서버를 재시작하지 않아도 Recomplie 로 편하게 가능

준영속 엔티티란 ?영속성 엔티티가 더는 관리하지 않는 엔티티를 말한다. 준영속 엔티티를 수정하는 2가지 방법변경 감지 기능 사용병합(merge) 기능 사용변경 감지 기능영속성 컨텍스트에서 엔티티를 다시 조회한 후에 데이터를 수정하는 방법트랜잭션 안에서 엔티티를 다시 조