IoC / DI / POJO

1. IoC

Inversion of Control (제어의 역전) 원칙

• 객체의 생명 주기 관리를 스프링(IoC)컨테이너가 도맡아서 해준다.

⁉ 필요 용어
제어
객체를 직접 생성하여 코드를 “제어” 한다. 생성자 내부에서 직접 생성하여 필드를 초기화함.

 //--- 직접 제어 ---
class A {
	private B b;
  public A() { //A라는 생성자 내부에 B를 직접 생성하여 필드 초기화
		this.b = new B();
	}
// A를 생성하려면 B가 필수임. 즉, B가 A의 생성 및 생명주기를 제어함.

Bean
스프링 컨테이너가 생성하고 관계설정, 사용을 제어해주는 오브젝트를 말함

• 스프링 IoC 컨테이너가 관리하는 자바 객체
• component-scan을 통해 패키지에 속한 객체들을 빈으로 등록 해줌.
  • @annotation 필수
    • @Component 에서 역할 별로 Service, Repository, Controller로 나뉨
    • Service = 비지니스 로직 처리
    • Repository = Dao를 상속받는 클래스 (DB 연동 처리)
    • Controller = 사용자 요청을 제어하는 Controller 클래스 처리

❓왜 IoC를 사용 해야 하는가?

기존에는 개발자가 흐름 제어(코드)를 했다.

• 기존에는 각 객체들이 프로그램의 흐름을 결정함.
• 개발자가 각 객체들을 생성하고 조작하는 작업(객체 생성 및 메소드 호출)을 했음. → 모든 작업을 개발자가 담당하게 됨.
  

직접 제어하는 경우의 단점

• B가 수정되는 경우 A 객체 또한 수정해야 줘야 함.
• 결합도가 높고 이로인해 확장성이 좋지 않고, 수정이 어려움.

제어의 역전

class A {
	private B b;

  public A(B b) { //외부로 부터 B를 받아서 초기화 함. 제어 흐름을 외부에서 관리 함.
		this.b = b;
	}
// 이미 결정된 B를 받기 때문에 A는 수정할 필요가 없어진다

➡️ 변경이 있을 때 수정이 쉬움.

• 유연하고 확정성이 뛰어남
• 클래스의 의존도가 줄어들었다. 결합이 느슨해짐.
• 관심사의 분리가 잘 이뤄졌다. → AOP 로 이어짐.

🌱 Spring IoC

객체의 생명주기 관리를 컨테이너가 도맡아서 하게 된다.

컨테이너가 직접 Bean(자바 객체)을 생성/관리 해주기 때문에 개발자는 코드에 객체를 선언하지 않아도 된다!

IoC Container

1) BeanFactory

BeanFactory 인터페이스는 IoC컨테이터의 기능을 정의하고 있는 인터페이스이며, Bean의 생성 및 의존성 주입, 생명주기(lifecycle) 관리 등의 기능을 제공한다. 여기서 Bean이란 IoC컨테이너에 의해 생성되고 관리되는 객체를 의미한다.

2) ApplicationContext

BeanFactory 인터페이스를 상속받는 ApplicationContext는 BeanFactory가 제공하는 기능 외에 AOP, 메세지처리, 이벤트 처리 등의 기능을 제공한다.

모든 ApplicationContext 구현체는 BeanFactory의 기능을 모두 제공하므로, 특별한 경우를 제외하고는 ApplicationContext를 사용하는 것이 바람직하다.

→ 객체(Bean)의 생명주기 관리를 해줌.

—

흐름 및 관계 : https://kingofbackend.tistory.com/77

—

📌 HollyWood Principle

전화하지 마세요. 우리가 연락할게요(Don't call us, we'll call you). → GoF 디자인패턴의 종류

• 주도권 없이 호출을 기다린다.

📌 Dependency Inversion Principle (의존 방향 역전), 의존 관계 분리 와 IoC 관계

객체 내부에서 인터페이스(추상화)를 인자로 받아서 변경에 자유로워짐.

IoC와 DIP 의 목적 : 클래스간 결합을 느슨히 하기 위함.

→ IoC와 DIP 시너지 효과가 높기 때문에 함께 사용 하도록 권장.

---

2. DI

Dependency Injection, 다른 프레임워크와 달리 의존관계를 주입해주는 스프링의 기능. IoC를 지키기 위한 패턴 중에 하나로 볼 수 있다.

😒 Dependency 의존관계란?

• A가 B를 의존할 때, B를 수정하게 되면 A에도 영향을 미친다.
• 의존관계를 인터페이스로 추상화하면 다양한 의존 관계를 가질 수 있게 되어 결합도가 낮아진다.

  class myCar{ //예제 수정
  	private Car car;
    public myCar() {
  		this.car = new Bus();
  	//Car = new myCar();
  	//Car = new taxi();

😒 DI (의존관계 주입) 란?

• 위 코드처럼 class 내부에서 정하는 것이 아닌 클래스 외부에서 결정하고 주입해주는 방식

  class myCar{ //예제 수정
  	private Car car;
  
    public myCar(Car car){
  		this.car = car;
  	}
  
  main () {
  	new myCar(new Bus());
    new myCar(new taxi()); //.. 등
  }

Spring에서의 DI 구현 방법

💡 @ 필드 주입
수동으로 의존성을 주입할 수가 없기 때문에 의존성이 프레임워크에 강하게 종속 된다. (테스트 불가)
현재는 권장되지 않는 방법이다.

💡 @ setter 주입
의존성을 선택적으로 주입할 때 사용 된다. 주입받는 객체가 변할 경우.

• 파이널 필드를 만들 수 없고, 의존성의 불변을 보장할 수 없다!
• 객체가 생성되지 않았을 때도 주입할 수 있어서 NULL에러가 발생할 수 있음.

💡 @ 생성자 주입

Spring에서 공식적으로 추천하는 방법이다.
의존성 주입이 생성자 호출 시 최초 1회만 이루어지기 때문에 파이널 필드를 만들 수 있고 불변성을 보장할 수 있다.
파이널필드이기 때문에 NullPointerException을 방지할 수 있음.

---

3. POJO

❓ POJO (Plain Old Java Object) 란?

오래된 방식의 간단한 자바 오브젝트라는 의미 이다. 특정 기술에 종속되어 동작하는 것이 아닌 순수한 자바 객체를 말함. EJB 같이 복잡하고 제한이 많은 기술의 대안으로 등장 !

• EJB(Enterprise Java Bean) : 기업 환경 시스템을 구현하기 위한 서버(기업 업무 로직 처리)

  -대표적인 POJO 기반 프레임워크 : Spring, hibernate 등 있다.

🚫 API 사용(특정환경종속) 및 상속 금지(단일상속위배)

❓ 왜 POJO를 지향해야 하는가??

스프링 이전에 필요한 기술이 있으면 기술을 직접적으로 사용하는 객체를 설계하였음.
이 방식으로 인해 특정 기술과 환경에 종속되어 가독성과 함께 유지보수 및 확장성이 매우 떨어지게 됨.

→ 이를 POJO를 통해 해결하여 본래 자바의 장점인 객체지향를 살리는 순수한 자바 객체를 구현할 수 있게 된다.

❗그럼 ORM을 사용하는 경우에는 어떻게 POJO를 유지할 수 있는가?

• 스프링프레임워크에서 JPA라는 표준 인터페이스를 정해두어 JPA 아래에 구현되어 실행됨.
  • 이러한 방법을 PSA라고 함 (PSA는 쉽게 말해서 Service의 추상화, 여러 기술들을 내부에 숨기고 개발자의 편의성을 올려줌.)

💡 JPA 란 자바 진영에서 ORM 기술 표준으로 사용되는 인터페이스의 모음.

POJO 프레임워크

💡스프링은 POJO를 이용한 엔터프라이즈 애플리케이션 개발을 목적으로 하는 프레임워크라 한다.