학원수업_71day [Spring] - IOC / DI / AOP 예습

Spring 수업 시작하기 전에 강사님께서 IoC 와 DI , AOP 를 한번 훑고 오라 하셨는데

간단히 적어보자.

스프링의 두 가지 특징이 있는데 그건 바로 IoC 와 DI 이다.

 

* Bean *

 'Bean'이란 무엇일까? 

Bean이란, 스프링 IoC 컨테이너가 생성하고 관리하는 애플리케이션 객체를 의미한다.

Bean은 deault가 singleton scope이고, bean 정의에 대해 container에 단 하나의 객체만 존재한다. 

scope의 종류에는 prototype, session, request 등이 있다.

 

스프링 컨테이너에는 두 종류가 있다

- BeanFactory : 빈 객체를 생성, 관리하는 클래스로, factory pattern을 구현한 것이다. 팩토리는 의존성 주입을 통해 빈 객체를 생성, 관리한다.

 

- ApplicationContext : 빈 팩토리와 유사하지만 향상된 형태의 컨테이너로, 이미지 파일 로드, 국제화 지원 텍스트 메시지관리 등의 추가 기능을 제공한다. 

---

DI(Dependency Injection) - 의존성 주입

객체를 직접 생성 하는게 아니라 외부에서 주입하는 방식

• A라는 클래스 내부에 has a 관계로 B클래스를 포함을 시키면 A클래스는 B에 의존적이다 라고 말을 하는데, 이 말을 쉽게 풀어 쓰면 A라는 클래스가 작동하기 위해서는 B가 필요하다는 의미가 된다.
• 스프링에서는 객체를 Bean이라고 부르며, 스프링에서는  프로젝트가 실행될때 사용자가 Bean으로 관리하는 객체들을 자동으로 생성해준다.
• A라는 클래스와 B라는 클래스 C라는 클래스에서 D라는 클래스를 요청했을때 스프링에서는 실행될때 생성했던 Bean을 주입 시켜주는데 이 과정을 DI라고 한다.

사용하는 방법으론 두 가지가 있다.

 

1. **new( )**를 통한 객체 생성

2. 외부에서 생성된 객체를 setter( ) 혹은, 생성자를 통해 사용하기

---

Ioc(Inversion of Control)

IoC(Inversion of Control)란 "제어의 역전" 이라는 의미로, 말 그대로 메소드나 객체의 호출작업을 개발자가 결정하는 것이 아니라, 외부에서 결정되는 것을 의미한다.

IoC는 **제어의 역전이라고 말하며, 간단히 말해 "제어의 흐름을 바꾼다" **라고 한다.

객체의 의존성을 역전시켜 객체 간의 결합도를 줄이고 유연한 코드를 작성할 수 있게 하여 가독성 및 코드 중복, 유지 보수를 편하게 할 수 있게 한다.

기존에는 다음과 순서로 객체가 만들어지고 실행되었다.

1. 객체 생성
2. 의존성 객체 생성클래스 내부에서 생성
3. 의존성 객체 메소드 호출

하지만, 스프링에서는 다음과 같은 순서로 객체가 만들어지고 실행된다.

1. 객체 생성
2. 의존성 객체 주입 스스로가 만드는 것이 아니라 제어권을 스프링에게 위임하여 스프링이 만들어놓은 객체를 주입한다.
3. 의존성 객체 메소드 호출

스프링이 모든 의존성 객체를 스프링이 실행될 때 다 만들어주고 필요한 곳에 주입시켜줌으로써 Bean들은 싱글턴 패턴의 특징을 가지며,

제어의 흐름을 사용자가 컨트롤 하는 것이 아니라 스프링에게 맡겨 작업을 처리하게 된다.

• ApplicationContext 혹은 BeanFactory
  • ApplicationContext는 BeanFactory를 상속받으므로 둘 다 같은 일을 하는 것임

스프링에서의 의존성 주입은 반드시 Bean으로 등록된 객체들 끼리만 가능.

스프링 IoC 컨테이너는 Bean으로 등록되지 않은 객체에는 의존성 주입을 해 주지 않습니다.

---

스프링 AOP ( Aspect Oriented Programming )

관점 지향 프로그래밍 이라고 불린다.

관점 지향은 쉽게 말해 어떤 로직을 기준으로 핵심적인 관점 / 부가적인 관점으로 나누어서 보고 그 관점을 기준으로 각각 모듈화 하겠다는 것이다 여기서 모듈화란 어떤 공통된 로직이나 기능을 하나의 단위로 묶는 것을 말한다.

예를 들어 핵심적인 관점은 비즈니스 로직이 될 수 있고,

부가적인 관점은 핵심 로직을 실행하기 위해 행해지는 데이터베이스 연결, 로깅, 파일 입출력 등이 될 수 있다.

• 이때, 소스 코드상에서 다른 부분에 계속 반복해서 쓰는 코드들을 발견할 수 있는 데 이것을 흩어진 관심사 (Crosscutting Concerns) 라 부른다.

[그림 1]과 같이 클래스 A, B, C에서 공통적으로 나타나는 색깔 블록은 중복되는 메서드, 필드, 코드 등이다.

이때 예를 들어 클래스 A의 주황색 블록 부분을 수정해야 한다면 클래스 B, C의 주황색 부분도 일일이 찾아 수정해야 한다.

이는 SOLID원칙을 위배하며 유지보수를 어렵게 만든다.

 

이런 식으로 소스 코드상에서 계속 반복해서 사용되는 부분들을  **흩어진 관심사(Crosscutting Concerns)**라고 한다.

→ 결국 AOP에서 각 관점을 기준으로 로직을 모듈화한다는 것은 흩어진 관심사를 모듈화 하겠다는 의미다.

[그림 1]과 같이 주황색, 파란색, 빨간색 블록처럼 모듈화 시켜놓고 어디에 적용시킬지만 정의해주면 되는 것이다.

이때 모듈화 시켜놓은 블럭을 Aspect 라고 한다.

AOP 주요 개념

• Aspect : 위에서 설명한 흩어진 관심사를 모듈화 한 것. 주로 부가기능을 모듈화함.
• Target : Aspect를 적용하는 곳 (클래스, 메서드 .. )
• Advice : 실질적으로 어떤 일을 해야할 지에 대한 것, 실질적인 부가기능을 담은 구현체
• JointPoint : Advice가 적용될 위치, 끼어들 수 있는 지점. 메서드 진입 지점, 생성자 호출 시점, 필드에서 값을 꺼내올 때 등 다양한 시점에 적용가능
• PointCut : JointPoint의 상세한 스펙을 정의한 것. 'A란 메서드의 진입 시점에 호출할 것'과 같이 더욱 구체적으로 Advice가 실행될 지점을 정할 수 있음

스프링 AOP 특징

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