웹 프로그래밍 (66) 썸네일형 리스트형 스프링 빈 가져올때 팁 조회 대상 빈이 2개 이상일때 1.@Autowired 필드 명 매칭 -타입 매칭 -타입 매칭 결과가 2개 이상일때는 필드명, 파라미터명(첫소문자 주의) 으로 빈 이름 매칭 2.@Quilifier -> @Quilifier 이름끼리 매칭(추가 구분자), 단 모든 선언앞에 @Quilifier을 붙여 주어야함 3.@Primary 사용: 여러 빈 매칭되면 @Primary가 우선권을 가짐 @Quilifier가 @Primary보다 우선순위가 높음(구체적) 조회한 빈이 모두 필요할때 List, Map 사용 자동,수동의 올바른 기준 -트렌드는 자동을 선호 -업무 로직 빈(자동) -컨트롤러, 핵심 비지니스 로직, 데이터 계층의 로직을 처리하는 리포지토리등, 비지니스 요구사항을 개발할때 추가 및 변경 -단 다형성을 적극활용.. 의존관계 자동 주입 다양한 의존관계 주입 방법 생성자 주입 -생성자 호출시점에 1번만 호출되는것이 보장 -불변, 필수(private final) 수정자 주입 -setter 주입 -선택 e.g. @Autowired(require = false) -변경 가능성이 있는 의존관계에 사용 필드 주입 -필드앞 에다가 @Autowired 를 직접함 -안티 패턴: 외부에서 변경이 불가능해서 테스트 어려움(쓰지 말것) 일반 메서드 주입 - 일반 메서드를 통해서 주입(setter와 유사) - 잘사용하지 않음 @Autowired는 스프링 컨테이너에 등록된 스프링 빈만 가능한 기능임 컴포넌트 스캔 컴포넌트 스캔 설정정보가 없어도 자동으로 스프링 빈을 등록하는 컴포넌트 스캔 기능 제공 @ComponentScan이 붙은 Config클래스를 통해 @Component가 붙은 클래스를 스프링 빈 객체로 등록(이름은 첫글자가 소문자가됨) 의존관계도 자동으로 주입하는 @Autowired와 함께 쓰임(타입으로 찾아서 주입) 탐색위치와 기본 스캔 대상 basePackeage로 컴포넌트 스캔할 시작위치 지정(하위 포함) 지정하지 않으면 @ComponentScan이 붙은 클래스의 패키지를 시작위치 지정(디폴트가 관례) 싱글톤 패턴 왜 싱글톤? -(기존) 클라이언트가 요청할때마다 객체가 생성 -> 메모리 낭비 -해결책: 해당 객체를 한개만 생성하고 공유하도록 설계 -클래스의 인스턴스가 딱 1개만 생성되는것을 보장하는 디자인 패턴 -e.g. static 영역에 객체 instace를 미리하나 생성하고 getInstance()메서드를 통해서만 조회 -생성자를 private 막아서 new 키워드로 객체 인스터스가 생성되는것을 막음 -하나의 객체만을 쓰기 때문에 시스템 효율증가 -단점 - DIP 위반(클라이언트가 구체 클래스에 의존) e.g. 구체클래스.메서드() - OCP 위반 - 테스트하기 어려움(설정이 이미 끝남) - 유연성이 떨어짐 싱글톤 컨테이너 -싱글톤 패턴의 모든 문제점을 해결하면서 객체 인스턴스를 싱글톤으로 관리(스프링 빈 객.. 스프링 컨테이너와 스프링 빈 스프링 컨테이너 -ApplicationContext는 인터페이스이며 스프링 컨테이너임 -new AnnotationConfigApplicationContext(AppConfig.class); 에서 AppConfig.class로 구성정보 지정 스프링 컨테이너 안 스프링 빈 저장소 빈 이름(key) 빈 객체(value) AppConfig.class 클래스 정보를 사용해서 @Bean이 붙은 메세드를 호출하여 스프링 빈 등록(네임, 객체) 스프링 컨테이너는 설정정보를 참고해서 의존관계를 주입(DI) 스프링 빈의 라이프 사이클 -객체생성 단계 -> 의존관계 주입 단계 (예외, 생성자 주입은 객체생성때 의존관계 주입) 스프링 빈 조회-상속관계 -부모 타입으로 조회하면, 자식 타입도 함께 조회함(다 끌고옴) -e.g... IoC, DI, 컨테이너 제어의 역전 IoC(Inversion of Control) -(기존) 구현체가 프로그램의 제어 흐름을 스스로 조종 -> AppConfig가 모든 제어 흐름의 권한을 가짐 -프로그램의 제어 흐름을 직접 제어가 아닌 외부에서 관리하는것을 제어의 역전이라 함 -작성한 코드를 제어하고 대신 실행 -> 프레임 워크(JUnit) -개발자가 작성한 코드가 직접 제어 흐름을 담당 -> 라이브러리 의존관계 주입 DI -실행 시점에 외부에서 실제 구현체를 생성하고 클라이언트에 전달해서 서버와의 실제 의존관계가 연결되는것 -정적인 클래스 의존관계: 애플리케이션 실행하지 않고 분석가능(클래스 다이어그램) -정적인 클래스 만으로는 실제 어느 구현체를 사용했는지 알수없음 -동적인 객체 인스턴스 의존관계: 애플리케이션 실행 시점에.. AppConfig AppConfig 인터페이스 뿐만아니라 구현체까지 의존하는 문제를 어떻게 해결할까? (DIP 위반) -> 애플리케이션의 전체 동작 방식을 설정(config)하기 위해 구현 객체를 생성하고 연결해주는 책임을 가지는 설정클래스를 만듦 생성자 주입: 생성자를 통해서 구현체를 넣어줌 -> 클라이언트는 인터페이스만 의존함 DI(Dependency Injection) 의존관계 주입: 클라이언트 입장에서는 마치 외부에서 의존관계를 주입해주는것 처럼 보임 AppConfig에서는 역할과 구현 클래스가 한눈에 들어옴(설계도), 사용영역의 코드는 바꾸지 않고 구성영역의 코드만 자유롭게 교체가능 좋은 객체 지향 설계의 5가지 원칙 적용 -SRP: 클라이언트 객체는 실행하는 책임, AppConfig는 구현체 생성과 연결하는 책.. 좋은 객체 지향 설계의 5가지 원칙(SOLID) SOLID -SRP(Single responsibility principle) 단일 책임 원칙 -중요한 기준은 변경임(변경시 파급효과가 적어야함) -OCP(Open/Closed principle) 개방-폐쇄 원칙 -확장에는 열려있으나 변경에는 닫혀있음(역할과 구현) -그러나 구현 객체를 변경하려면 클라이언트 코드를 변경해야함(OCP 위반) -LSP(Liskov substitution principle) 리스코프 치환 원칙 -인터페이스 규약,의도 맞게 구현 -ISP(Interface segregation principle) 인터페이스 분리 원칙 -범용 인터페이스 하나보다 여러개의 인터페이스가 더 좋음(독립, 명확, 대체가능성) -DIP(Dependency inversion principle) 의존관계 역전.. 이전 1 ··· 5 6 7 8 9 다음