Spring DI 컨테이너가 관리하는 객체를 빈이라고 한다.
관리한다는 의미로 컨테이너를 빈 팩토리라고 부른다.

빈팩토리

bean을 등록 생성 조회 반환 관리함.

getBean()메서드가 정의되어있다. bean xml에 작성 후 getBean(bean이름,클래스명.class)으로 접근가능.

setter injection-setter메서드를 이용한 의존성 삽입 - <property>

constructor injection-생성자를 이용한 의존성 삽입-setter와의 차이는 생성자 주입은 생성자의 파라미터를 사용하기 때문에 여러개의 객체주입가능 - <constructor-arg>사용

method injection-일반 메서드를 이용한 의존성 삽입

DL-dependency Lookup 컨테이너에 저장된 bean에 접근하기 위해 컨테이너가 제공하는 API를 이용해 bean을 Lookup함
DI-Dependency Injection 각 클래스간의 의존관계를 빈 설정 정보를 바탕으로 컨테이너가 자동으로 연결해주는것.

Maven은 자바용 프로젝트 관리도구로 Apache Ant의 대안으로 만들어졌다.

Maven은 Ant와 마찬가지로 프로젝트의 전체적인 라이프 사이클을 관리하는 도구 이며, 많은 편리함과 이점이 있어 널리 사용되고 있다.
Maven은 필요한 라이브러리를 특정 문서(pom.xml)에 정의해 놓으면 내가 사용할 라이브러리 뿐만 아니라 해당 라이브러리가 작동하는데에 필요한 다른 라이브러리들까지 관리하여 네트워크를 통해서 자동으로 다운받아 준다.

Maven은 중앙 저장소를 통한 자동 의존성 관리를 중앙 저장소(아파치재단에서 운영 관리)는 라이브러리를 공유하는 파일 서버라고 볼 수 있고, 메이븐은 자기 회사만의 중앙 저장소를 구축할수도 있다.

간단한 설정을 통한 배포 관리가 가능 하다.

 Ant vs Maven

1. Ant는 비교적 자유도가 높은 편
    (Ant : 전처리 / 컴파일 / 패키징 / 테스팅 / 배포 가능)

2. Maven은 정해진 라이프사이클에 의하여 작업 수행하며, 전반적인 프로젝트 관리 기능까지 포함.
    (Build Tool + Project Management)

출처: https://goddaehee.tistory.com/199 [갓대희의 작은공간]

Spring 개발업체인 SpringSource가 직접 만들어 제공하는 이클립스의 확장판.
Spring 개발에 최적화 되도록 만든 Integrated Development Environment, IDE 이다.

Maven 라이브러리 관리 + 빌드(자바 코드를 컴파일하고 jar로 묶어주고,배포하고) 툴
편리한 Dependency Library관리, 여러프로젝트에서 프로젝트 정보나 jar파일들을 공유하기 쉽다.
빌드 프로세스를 일관되게 가져갈수 있다.

빌드란?

 - 소스코드 파일을 컴퓨터에서 실행할 수 있는 독립 소프트웨어 가공물로 변환하는 과정 또는 그에 대한 결과물 이다.
 - 이를 좀더 쉽게 풀어 말하자면 우리가 작성한 소스코드(java), 프로젝트에서 쓰인 각각의 파일 및 자원 등(.xml, .jpg, .jar, .properties)을 JVM이나 톰캣같은 WAS가 인식할 수 있는 구조로 패키징 하는 과정 및 결과물이라고 할 수 있다.

빌드 도구(Build tool)

 - 빌드 도구란 프로젝트 생성, 테스트 빌드, 배포 등의 작업을 위한 전용 프로그램.
 - 빠른기간동안 계속해서 늘어나는 라이브러리 추가, 프로젝트를 진행하며 라이브러리의 버전 동기화의 어려움을 해소하고자 등장.
 - 초기의 java 빌드도구로 Ant를 많이 사용하였으나 최근 많은 빌드도구들이 생겨나 Maven이 많이 쓰였고, 현재는 Gradle이 많이 쓰인다.
(Ant는 스크립트 작성도 많고, 라이브러리 의존관리가 되지 않아 불편함)

출처: https://goddaehee.tistory.com/199 [갓대희의 작은공간]

제네릭 타입을 부모클래스로 사용할 경우

타입 파라미터는 자식클래스에도 기술해야 한다. 

추가적인 타입 파라미터를 가질수 있다. (부모가 제네릭이면 자식도 제네릭이다. 자식은 타입 파라미터를 추가로

가질수 있다.)

제네릭 인터페이스를 구현할 경우

타입 파라미터는 구현 클래스에도 기술해야한다. (부모가 제네릭이면 자식도 제네릭)

와일드카드(?)란 제네릭타입을 매개변수나 리턴타입으로 사용할 때 타입 파라미터를 제한할 목적으로 사용한다.

와일드카드에는 세가지 형태가 있다.

1. 제네릭타입<?> - 제한이 없다. 모든 클래스나 인터페이스 타입이 올수 있다

2. 제네릭타입<? extends 상위타입> - 상위클래스를 제한함. ?는 상위타입 또는 그 자식만 가능

3. 제네릭타입<? super 하위타입> - 하위클래스를 제한함. ?는 하위타입 또는 그 부모만 가능

타입 파라미터에 지정되는 구체적인 타입을 제한하고 싶을때 사용한다.

아래 예제를 보자.

<T extends Number> 라고 타입 파라미터를 지정했다.

T 에 Number객체가 오거나 Number의 자식만 파라미터로 올수 있다는 뜻이다.

그러므로 Number의 자식이 아닌 String객체를 파입 파라미터로 지정하면 컴파일 에러가 난다.

그리고 Double과 int 타입은 모두 Number의 자식이므로 사용가능하다.

이렇게 제한을 둘수가 있다. (여기서 extends란 ~가 ~를 포함한다. 는 뜻이다. 인터페이스 상속이라도 <>에선

extends를 사용해야한다.