프레임워크 라이브러리 차이점

• 프레임워크는 규약을 지켜야하고 라이브러리는 도구
• 라이브러리를 사용하는 애플리케이션 코드는 애플리케이션 흐름을 직접 제어
  동작중에 필요한 기능이 있어서 능동적으로 라이브러리를 사용함
• 프레임워크는 거꾸로 애플리케이션 코드가 프레임워크에 의해 사용됨
  애플리케이션 코드는 프레임워크가 짜 놓은 틀에서 수동적으로 동작해야함
• "제어 흐름"의 권한이 어디있냐의 차이
• 스프링 프레임워크!

IoC(Inversion of Control) & Container

• 필요할때 만들어쓰는게 아니라 미리 만들어놓고 필요할때 쓴다

• 객체지향 언어에서 object간의 연결 관계를 런타임에 결정

• 객체 간의 관계가 느슨하게 연결된다 : ioc를 사용을 하면!
  -> B라는 클래스가있고 B가 A객체를 생성한다
  A라는 클래스의 메소드를 호출할거야
  만약에 A의 메소드 리턴타입이 바뀌면 B도 바꿔야함..
  어느 한쪽이 바뀌면 다른쪽도 바뀌어야하는게 타이트한 결합-> 이걸 방지하기 위해서, 어느한쪽이 바뀌면 다른쪽을 바꿔야하는 클래스와 클래스간의 약속인 인터페이스! 인터페이스로 인해 느슨한 연결로 변함,

• setter,constructor,method 세가지있는데 스프링에서 권장하는건 Constructor

• 디펜던시 룩업 : 컨테이너가 미리 만들어놓고 필요할때 찾음 , jndi

• 디펜던시 인젝션: 룩업코드조차도 안쓰고, 나는 만든적도 찾은적도 없는데 내 클래스 안에서 자동으로 사용할 수 있다.

• 컨테이너 : 라이프사이클 담당, 팩토리 패턴 or 싱글톤 패턴을 직접 구현하지 않아도 됨

• IoC Container : BeanFactory, applicationContext-> 얘를 쓸거임

• spring di container : bean을 등록, 생성, 조회, 반환, 일반적으로 applicationcontext 사용

• 결합도 높으면 한쪽 바뀌면 한쪽도 바꿔야함

• 팩토리이면서 싱클톤 거기다 객체를 생성하는거까지 해주는게 , 주입까지.. 스프링컨테이너

• 팩토리 역할을 스프링 컨테이너가 알아서 해준다

• 설정 : xml , java -> annotation

---

디펜던시 인젝션
의존성 주입

• 주입방법 3가지있음 : 일단 Setter, Constructor 이렇게 두가지만 알면돼
  xml에 있는 클래스는 : 어떤 객체를 만들건지

id는?그럼 빈을 가지고 객체를 만드는거야? 객체 만들때마다 xml에 만들어줘?

<bean id="f4" class="sample5.Foo" c:str="스프링" c:n="10"
	c:flag="true"> 여기서 순서바꾸면 문제생기나요?
    id는 왜주는건가요?

• is-a : 상속 ! extends : 개는 동물이다 등과 같이 부모 클래스(일반적인 개념)을 자식클래스(구체적인개념)에서 구체화할 때 상속
• has-a : 포함 : 사람은 운전을 한다, 포함관계일 때, new로 생성자를 호출해서 다른 클래스를 사용함