002. IoC, AOP , DI, POJO 의 개념

 

1. IoC (Inversion of Control)

IoC 란 코드의 흐름을 제어하는 주체가 바뀌는 것이다.

코드의 흐름을 제어한다는 것은 여러 행위를 포함한다. 오브젝트를 생성하는 것, 오브젝트의 생명주기를 관리하는 것, 메소드를 수행하는 것 등. 그리고 일반적인 프로그램은 이러한 행위를 하나부터 열까지 모두 스스로 수행한다. (우리가 처음 만들었던 프로그램을 잘 생각해보자.) IoC 를 적용한다는 것은 이러한 흐름 제어를 또다른 제 3자가 수행한다는 것을 의미한다.

 

1) IoC에서는 Object가 자신이 사용할 Object를 생성하거나 선택하지 않는다.

2) Object는 자신이 어떻게 생성되고 사용되는지 알 수 없다. 

3) 모든 Object는 제어 권한을 위임받은 특별한 Object에 의해 만들어지고 사용된다.

 

객체의 생명주기를 스프링 컨테이너가 관리하는 IoC 개념이 있기 때문에, DL(Dependency Lookup) 과 DI(Dependency Injection)이 가능해진다.

 

2. DI (Dependency Injection)

DI is about how one object acquires a dependency

DI 는 필요로 하는 오브젝트를 스스로 생성하는 것이 아닌 외부로 부터 주입받는 기법을 의미한다. 마틴 파울러의 글에 따르면 3가지 타입으로 정의할 수 있다.

 

Constructor Injection

생성자를 통해 주입하는 방식이다. 인스턴스가 생성되었을 때 의존성이 존재하는 것이 보장되기 때문에 의존성의 존재여부가 보장되고 의존성을 immutable 하게 정의할 수 있다. 스프링에서도 해당 방식을 권장하는 것으로 알고 있다.

Setter Injection

Setter 메소드를 이용하여 주입하는 방식이다. 해당 방식은 Construcor Injection 보다 좀 더 주의를 요한다. 주입 받는 의존성의 기본값을 정의할 수 있지 않다면 null 값이 존재할 수 있는 이슈가 있기 때문이다. 의존성이 다시 주입되어야할 경우 유용하게 사용된다고 하나 나는 아직 그러한 상황을 겪지 못했고 모두 Construcor Injection 으로 해결할 수 있었다.

 

Interface Injection

Interface 로 주입받는 메소드를 정의한다. 이 방식은 이번에 조사하면서 처음 알게 되었고 실제로 사용해본 적이 없어 자세히 적기는 조심스럽다. 예시를 봐도 이점이 명확하게 보이지 않아 좀 더 공부를 하고 내용을 채워보려 한다.

 

 

 

3. AOP (Dependency Injection)

 

AOP는 Aspect Oriented Programming의 약자로 관점 지향 프로그래밍이라고 불린다. 관점 지향은 쉽게 말해 어떤 로직을 기준으로 핵심적인 관점, 부가적인 관점으로 나누어서 보고 그 관점을 기준으로 각각 모듈화하겠다는 것이다. 여기서 모듈화란 어떤 공통된 로직이나 기능을 하나의 단위로 묶는 것을 말한다.

 

예로들어 핵심적인 관점은 결국 우리가 적용하고자 하는 핵심 비즈니스 로직이 된다. 또한 부가적인 관점은 핵심 로직을 실행하기 위해서 행해지는 데이터베이스 연결, 로깅, 파일 입출력 등을 예로 들 수 있다.

 

AOP에서 각 관점을 기준으로 로직을 모듈화한다는 것은 코드들을 부분적으로 나누어서 모듈화하겠다는 의미다. 이때, 소스 코드상에서 다른 부분에 계속 반복해서 쓰는 코드들을 발견할 수 있는 데 이것을 흩어진 관심사 (Crosscutting Concerns)라 부른다. 

| AOP 주요 개념

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

 

| 스프링 AOP 특징

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

4. POJO (Plain Old Java Object)

스프링 프레임워크는 IoC(Inversion of Control, 제어의 역전) 컨테이너 안에서 POJO를 구성 및 관리하는 것이 가장 핵심으로 POJO를 매우 잘 다루는 프레임워크가 스프링 프레임워크이다.

 

Java EE 등을 사용할 때에 비해서 특정 인터페이스를 구현하거나 상속 할 필요 없고 라이브러리를 지원하기에 용이하며 객체 또한 가벼운 것이 특징이다.POJO를 이해하려면 POJO라는 단어가 만들어진 역사적 배경을 살펴볼 필요가 있다. POJO는 마틴 파울러가 2000년 가을에 열렸던 어느 컨퍼런스의 발표를 준비하면서 처음 만들어낸 말이다. 마틴 파울러는 EJB(Enterprise JavaBean)보다는 단순한 자바 오브젝트에 도메인 로직을 넣어 사용하는 것이 여러가지 장점이 있는데 왜 사람들이 EJB가 아닌 '평범한 자바 오브젝트'를 사용하기를 꺼려하는지에 대해 의문을 가졌다. 그리고 그는 단순한 오브젝트에는 EJB와 같은 그럴듯한 이름이 없어서 그 사용을 주저하는 것이라고 결론을 내렸고, POJO라는 용어를 만들었다.

출처: https://limmmee.tistory.com/8 [심플하게 개발]

출처: https://needjarvis.tistory.com/585 [자비스가 필요해]
출처: https://weicomes.tistory.com/451 [25%]

출처: https://engkimbs.tistory.com/746 [새로비]