• 스프링 런타임 엔진 : 스프링 컨테이너, Application 컨텍스트
• 서비스 추상화 : 특정 기술에 종속 되지 않는다. 이식성이 높다
• AOP - 부가기능을 독립적으로 모듈화
• 스프링의 모든 기술은 JavaEE에 기반을 둔다
• 스프링은 POJO 프로그래밍이다
• 프레임워크를 확장해도 버전 호환성 문제가 거의 없다.

1장

자바빈 ( 컴포넌트라기 보다는 )

• 디폴트 생성자 : 리플렉션으로 오브젝트를 생성하기 때문에 파라미터가 없는 디폴트 생성자를 가져야된다.
• 프로퍼티 : 자바빈이 노출하는 이름을 가진 속성 ( get, set )

  엔트리 포인트 : 프로세서가 프로그램이나 코드에 진입해 실행하는 것(결과적으로 main()함수)

• 관심사 분리 : 변화가 발생 -> 한 가지 관심이 한군데에 집중되는 것 -> 관심사 끼리 모으고, 관심이 다른 것은 따로 떨어져 있게 하는것
• 팩토리 메서드 : 서브클래스에서 오브젝트 생성 방법과 클래스를 결정할 수 있도록 미리 정의해둔 메서드 ( 오브젝트 생성 )
  --> 팩토리 메서드 패턴이나 템플릿 메서드 패턴은 상속을 사용하여 다중상속 X, 다른목적으로 상속 X, 다른 DAO에 적용하기 빡샘
  해결방안 : UserDAO에서 공통 로직을 메서드로 빼고 추상클래스로 만들어 상속 받게 함
  --> DB연결하는 getConnetion()을 다른 클래스로 분리하고 생성자를 통해 그 클래스를 받고 사용 ( 상속 문제 해결 )
  문제점 또 발생

1. 메소드가 A사에서는 AMethod, B사는 BMethod 면 다시 고쳐야됨 p.74
2. UserDAO가 구체적인 클래스를 알아야된다.
   해결방안 : 인터페이스를 사용하자 --> 하지만 생성자에 주입받을 때 구체적인 클래스 필요

• 이걸 또 클라이언트로 구체클래스를 정하도록 위임한다.

1-1 제어의 역전

• UserDAOTest(클라이언트)가 어떤 클래스를 주입할지에 대한 책임이 있다.(단지 Test 역할을 하는 클래스인데)
• UserDAO와 connectioMaker 구현클래스의 Object를 만드는 것과 연결되어 사용 가능하게 해야된다.
  해결방안 : 팩토리 사용하자
• 객체의 생성 방법을 결정하고 오브젝트 반환
• 추상 팩토리 메서드 패턴, 팩토리 메서드 패턴과는 다르다
• 오브젝트 생성 쪽, 사용하는 쪽의 역할과 책임 분리
• DaoFactory 생성 p.89

public class DaoFactory {
	public UserDao userDao(){
    	return new UserDao(connetionMaker());
    }
    
    public AccountDao accountDao(){
    	return new Account(connetionMaker());
    }
    
    public ConnectionMaker connetionMaker(){
    	return new DConnectionMaker(); // 분리해서 중복을 제거한 ConnectionMaker 타입 오브젝트 생성 코드
    }
}

라이브러리 : 애플리케이션 흐름을 직접 제어
프레임워크 : 애플리케이션 코드가 프레임워크에 의해 사용된다. -> IoC가 반드시 있어야된다.