일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 코딩테스트
- Git
- mariadb
- DISTINCT
- Linux
- AWS
- 프로그래머스
- TLS
- db
- window
- spring boot
- centos7
- docker
- Hibernate
- TypeScript
- 책 정리
- Jenkins
- Java
- EC2
- Spring Legacy Project
- WebHook
- 토비의스프링
- jdbc
- github
- ssh
- vagrant
- SSL
- Client
- spring
- sample
- Today
- Total
Woopii Vyeolog
IOC container, DIP, DI Framework 본문
Inversion of Control(IOC)
IOC : Inversion of Control (제어의 역전): 프로그래머가 작성한 프로그램이 재사용 라이브러리의 흐름 제어를 받게 되는 소프트웨어 디자인 패턴을 말한다.
전통적인 프로그래밍에서 흐름은 프로그래머가 작성한 프로그램이 외부 라이브러리의 코드를 호출해 이용한다. 하지만 제어 반전이 적용된 구조에서는 외부 라이브러리의 코드가 프로그래머가 작성한 코드를 호출한다. 설계 목적상 제어 반전의 목적은 다음과 같다.
- 작업을 구현하는 방식과 작업 수행 자체를 분리한다.
- 모듈을 제작할 때, 모듈과 외부 프로그램의 결합에 대해 고민할 필요 없이 모듈의 목적에 집중할 수 있다.
- 다른 시스템이 어떻게 동작할지에 대해 고민할 필요 없이, 미리 정해진 협약대로만 동작하게 하면 된다.
- 모듈을 바꾸어도 다른 시스템에 부작용을 일으키지 않는다
아래 자바 코드에서 스레드를 사용하는데, Runnable은 인터페이스이다. 그리고 run은 사용자가 오버라이드 하여 정의한 메서드이다. 이를 제어의 역전(IoC)이라고 함.
new Thread(new Runnable() {
@Override
public void run() {
// Do something
}
}).start();
Dependency Inversion Principle (DIP)
- Dependency Inversion Principle (의존관계 역전 원칙): 상위 모듈은 하위 모듈에 종속되어서는 안되며 인터페이스(추상화)에 의존해야한다.
얼핏 보기에는 IoC랑 비슷한듯 보이지만, 한가지 차이점이 있다면, IoC는 사용자가 구현한 인터페이스를 하위 모튤이 의존하든 말든 상관하지 않는다. 하지만 DIP는 의존 관계에 대한 것이기 때문에 하위 모듈은 상위 모듈의 has 관계(맴버 변수)가 되어야 한다.
interface IHeater {
public on();
public off();
}
interface IPump {
public pump();
}
public class CoffeeMaker { // 상위 모듈
private final IHeater heater; // 하위 모듈
private final IPump pump; // 하위 모듈
public CoffeeMaker(IHeater heater, IPump pump) {
this.heater = heater;
this.pump = pump;
}
public void brew() {
heater.on();
pump.pump();
heater.off();
}
}
J2EE Design Patterns
2000년대 초반 Context, Locator, Registers 등과 같은 이름을 가진 거대한 팩토리들이 소개되기 시작하면서, 많은 사람들이 J2EE 표준에 따라 이러한 코드들을 작성하기 시작했다. (J2EE가 유명했기 때문??)
public class ServiceLocatorTester {
public static void main(String[] args) {
ServiceLocator serviceLocator = ServiceLocator.getInstance();
try {
ProjectHome projectHome = (ProjectHome) serviceLocator
.getHome(ServiceLocator.Services.PROJECT);
} catch (ServiceException ex) {
// client handles exception
System.out.println(ex.getMessage());
}
}
}
이러한 거대 팩토리는 리펙토링 및 테스트 코드 작성을 어렵게 한다.
IoC Container
많은 개발자들이 거대한 팩토리를 사용하는 동안 1998년 한쪽에서는 Stefano Mazzocchi는 Avalon (1998~2005)이라는 Java Apache Server Framework를 발표함. 이 Avalon은 IoC를 적극적으로 차용해 컴포넌트간에 종속성을 외부에서 자동으로 해결주는 IoC bandwagon이라는 개념을 최초로 소개했으며, 인터페이스와 외부 메타 정보를 결합해 의존성을 해결하는 이 기술은 IoC Container라는 이름으로 알려져 OSGi, Spring, Pico, Hivemind, Guice 등 많은 프로젝트에 영향을 끼치게 된다.
DI Framework
2004년 1월 IoC Container에서 IoC가 매우 포괄적인 이름이라 혼동을 줄 수 있다며, 대신 Dependency Injection 이라는 용어를 사용하는것이 어떻겠나고 제안됨
따라서, DIP을 적용하여 작성한 상위 모듈에 의존하는 하위 모듈을 생성자, 프로퍼티, 메서드(Setter)를 통해 주입하는것을 Dependency Injection(DI)이라 하고, 설정에 따라 의존성을 자동으로 resolve 하여 주입해주는 기술을 통칭하여 DI Framework라고 부르게 된다.
- DI는 DI Framework 없이 직접 주입하는 것도 포괄하는 일반적인 개념.
- IoC Container는 좀 더 포괄적인 개념으로써 여전히 DI Framework와 혼용되어 사용되고 있음.
출처
'Spring Framework' 카테고리의 다른 글
Spring 다운, 설치, 한글 설정(UTF-8) (0) | 2020.03.16 |
---|---|
Spring FrameWork 에서 CSS파일 JS파일 가져오기가 안될 때 (2) | 2020.02.12 |
Bean VS POJO (1) | 2020.02.11 |
어노테이션(@) 간략 설명 (0) | 2020.02.10 |
MVC 모델 (0) | 2020.02.10 |