POJO (Plain Old Java Object)

• 오래된 방식의 간단한 자바 오브젝트
  (JavaEE등 중량 프레임워크를 사용하게 되면서 해당 프레임워크에 종속된 무거운 객체에 반발해서 사용되게 된 용어)
• 특정 '기술'에 종속되어 동작하는 것이 아닌 순수한 자바 객체
  ex) ORM 기술을 사용하기 위해서는 ORM을 지원하는 프레임워크를 사용해야한다(대표적으로 Hibernate) 자바 객체가 Hibernate 프레임워크를 직접 의존하는 순간 POJO라고 할 수 없음 - 특정 기술에 종속
• 왜 POJO를 지향해야 하나?
  특정 기술의 클래스를 상속 받거나, 직접 의존하게 되어 확장성이 떨어지게된다. 이는 객체지향 설계의 장점을 잃어버리게 되는 것이기때문!
• POJO를 유지하며 특정 기술을 사용하기 위한 PSA(Portable Service Abstraction)
  환경의 변화와 관계없이 일관된 방식의 기술 접근 환경을 제공하려는 추상화 구조
  ex) 스프링에서 ORM 기술을 사용하기 위해서 JPA라는 표준 인터페이스를 정해두었고 ORM 프레임워크들은 JPA라는 표준 인터페이스 아래에서 구현되어 실행된다.

IoC (Inversion of Control)

• 제어의 역전
• 메서드나 객체의 호출을 개발자가 결정하는 것이 아닌 컨테이너에 의해서 결정되는 것
• 객체의 생성부터 소멸까지의 생명주기 관리를 컨테이너(IoC Container)가 하기때문에 제어권을 컨테이너가 소유함
• 객체 간의 결합도를 줄이고 유연한 코드를 작성할 수 있게 함
• 스프링이 모든 의존성 객체를 실행될 때 전부 생성 후 필요한 곳에 주입
  → Bean은 싱글톤 패턴의 특징을 가진다.

IoC 객체 생성 방식

기존 : 객체 생성 → 의존성 객체 생성(클래스 내부에서 생성)
Spring : 객체 생성 → 의존성 주입(스스로 만드는 것이 아닌 제어권을 스프링에게 위임)

IoC 분류

• DL(Dependency Lookup)
  : 저장소에 저장되어 있는 Bean에 접근하기 위해서, 컨테이너가 제공하는 API를 사용하여 Bean을 Look Up 하는 것

• DI(Dependency Injection)
  : 각 클래스간의 의존관계를 빈 설정(XML 파일) 정보를 바탕으로 컨테이너가 자동으로 연결해주는 것

IoC 주요 용어

• Managed Bean
  스프링 컨테이너에서 관리하는 객체
  스프링 설정 파일에서 등록되어 사용되며 자동 등록 기능 사용이 가능(Component AutoScan, Autowired 등...)

• Spring Container
  Managed Bean 이 모여있는 곳
  IoC 컨테이너로서 Application Context 클래스로 구현

DI (Dependency Injection)

의존관계 : A라는 클래스가 B라는 클래스를 내부적으로 사용하게 되면 A는 B에게 의존하는 관계라고 한다.

• 의존성 주입
• 구체적인 의존 객체와 그것을 사용할 주체, 클라이언트 객체를 런타임 시에 연결해주는 작업
• 의존하고 있는 클래스가 변경되더라도 인터페이스를 통해 의존하고 있기때문에 구체 클래스를 변경하고 싶다면 의존 설정시에 다른 구체클래스를 명시하면 된다.
  → 객체 지향 설계 원칙인 OPC(개방 폐쇄 원칙), DIP(의존 역전 원칙)을 따르게 된다.
  → 결합도 낮아지면서 유지보수, 확장에 유리

* 개방 폐쇄 원칙 : 기능을 변경하거나 확장할 수 있으면서 그 기능을 사용하는 코드는 수정하지 않아야한다.
* 의존 역전 원칙 : 자신보다 변하기 쉬운 것에 의존하면 안된다.

DI 조건

• 클래스 모델이나 코드에는 런타임 시점의 의존관계가 드러나지 않는다.
  → 인터페이스에만 의존하고 있어야 함.
  (A 클래스는 B의 인터페이스에게 의존)
• 런타임 시점의 의존관계는 팩토리나 컨테이너 같은 외부에 의해 결정되어야 한다.
• 의존 관계를 사용할 객체에 대한 레퍼런스를 외부에서 제공해줌으로써 만들어진다.

AOP (Aspect Oriented Programming)

• 관점 지향 프로그래밍
• 흩어진 Aspect들을 모아서 모듈화하는 기법
• 서로 다른 클래스에서 비슷한 기능을 하는 부분을 Concern 이라고 하며 이 Concern 별로 Aspect로 모듈화하고 핵심적인 비즈니스 로직에서 분리하여 재사용

AOP 주요 개념

• Aspect : 흩어진 관심사를 모듈화 한 것(주로 부가기능)
• Target : Aspect를 적용하는 곳(클래스, 메서드 등)
• Advice : 실질적으로 어떤 일을 해야할지에 대한 것(부가기능을 담은 구현체)
• JointPoint : Advice가 적용 될 위치(끼어들 지점, 메서드 진입 지점, 생성자 호출 시점 등)
• PointCut : JointPoint의 상세한 스펙 정의(A 메서드의 진입시점에 호출할 것)

Spring AOP

• 프록시 패턴 기반의 AOP 구현체
  (프록시 객체를 쓰는 이유는 접근 제어 및 부가기능을 추가하기 위해)
• 스프링 Bean에만 AOP 적용 가능
• 모든 AOP 기능을 제공하는 것 X, 스프링 IoC와 연동하여 애플리케이션에서 가장 흔한 문제(코드 중복, 프록시 클래스 작성 번거로움 등)에 대한 해결책을 지원하는 것이 목적