"제어 반전"의 두 판 사이의 차이

 
(사용자 3명의 중간 판 10개는 보이지 않습니다)
1번째 줄: 1번째 줄:
==개요==
==개요==
;Inversion of Control; IoC
;Inversion of Control (IoC)
;제어의 역전, 제어 역전, 제어 반전, 제어의 반전, 역제어<ref>"제어의 역전" 5,900개, "제어 역전" 3,090개, "제어의 반전" 2,300개, "제어 반전" 1,760개</ref>
;제어의 역전, 제어 역전, 제어 반전, 제어의 반전, 역제어<ref>"제어의 역전" 5,900개, "제어 역전" 3,090개, "제어의 반전" 2,300개, "제어 반전" 1,760개</ref>
* 추상화 원칙의 한가지
* 추상화 원칙의 한가지
* 제어 흐름 구조가 뒤바뀌는 것
* 제어 흐름 구조가 뒤바뀌는 것
* 실행에 필요한 객체의 생성·사용 등 제어 권한을 위임하는 것
* 실행에 필요한 객체의 생성·사용 등 제어 권한을 위임하는 것
* 절차적 프로그래밍과 비교했을 때 시스템 제어흐름이 역전되어 있는 소프트웨어 아키텍처 설계
* 절차적 프로그래밍과 비교했을 때<ref>기존 절차적 프로그래밍에서는 개별적으로 개발한 코드가 그 프로그램의 목적을 표현하고, 범용적인 태스크를 수행할 경우 재사용가능한 라이브러리를 호출하는 형태임</ref>, 시스템 제어흐름이 역전되어 있는 소프트웨어 아키텍처 설계
* 개별 목적에 따라 쓰인 코드 부분이 일반적이고 재사용가능한 라이브러리의 흐름 제어를 받는 형식의 설계
* 개별 목적에 따라 쓰인 코드 부분이 일반적이고 재사용가능한 라이브러리의 흐름 제어를 받는 형식의 설계
* 예시: 서블릿(기능 정의)-컨테이너(실제 수행), [[템플릿 메소드 패턴]], [[프레임워크]]<ref>제어 역전 구조인지 여부를 프레임워크와 라이브러리를 구분하는 기준으로 삼기도 함</ref>
* 예시: 서블릿(기능 정의)-컨테이너(실제 수행), [[템플릿 메소드 패턴]], [[프레임워크]]
:제어 반전 구조인지 여부를 프레임워크와 라이브러리를 구분하는 기준으로 삼기도 한다.
* [[의존성 주입]]은 "제어 반전"을 구현하는 주된 방법이다.


==목적==
==목적==
*한 태스크의 실행을 구현에서 분리함
* 한 태스크의 실행을 구현에서 분리한다.
*모든 시스템이 설계 목적에 집중하게
* 모든 시스템이 설계 목적에 집중하게 한다.
*다른 시스템이 무엇을 할지 추측하지 않아도
* 다른 시스템이 무엇을 할지 추측하지 않아도 된다.
*시스템을 바꿔도 다른 시스템에 부작용을 주지 않음
* 시스템을 바꿔도 다른 시스템에 부작용을 주지 않는다.


==예시==
==예시==
<source lang='java'>
<syntaxhighlight lang='java'>
public class ServerFacade {
public class ServerFacade {
public Object respondToRequest(Object pRequest) {
public Object respondToRequest(Object pRequest) {
27번째 줄: 29번째 줄:
}
}
}
}
</source>
</syntaxhighlight>
<source lang='java'>
<syntaxhighlight lang='java'>
public class ServerFacade {
public class ServerFacade {
public Object respondToRequest(Object pRequest) {
public Object respondToRequest(Object pRequest) {
34번째 줄: 36번째 줄:
}
}
}
}
</source>
</syntaxhighlight>


==같이 보기==
==같이 보기==
*[[디자인 패턴]]
{{z컬럼3|
*[[Hollywood 원칙]]
* [[콜백]]
*[[의존성 뒤집기 원칙]]
* [[XSLT]]
*[[의존성 주입 DI]] ★
* [[전략 패턴]]
*[[콜백]]
* [[델리게이트]]
*[[델리게이트]]
* [[의존성 주입]] ★
*[[인터럽트 핸들러]]
* [[디자인 패턴]]
*[[Observer 패턴]]
* [[옵저버 패턴]]
*[[발행-구독 모델]]
* [[방문자 패턴]]
*[[Strategy 패턴]]
* [[헐리우드 원칙]]
*[[Visitor 패턴]]
* [[발행-구독 모델]]
*[[XSLT]]
* [[인터럽트 핸들러]]
*[[프레임워크, 라이브러리 차이]]
* [[의존성 뒤집기 원칙]]
*[[스프링 IoC 컨테이너]]
* [[스프링 IoC 컨테이너]]
* [[프레임워크, 라이브러리 차이]]
}}


==참고 자료==
==참고==
*https://en.wikipedia.org/wiki/Inversion_of_control
* {{위키백과|제어 반전}}
* {{영어위키백과|Inversion_of_control}}


[[분류: 디자인 패턴]]
[[분류: 디자인 패턴]]

2022년 3월 31일 (목) 09:34 기준 최신판

1 개요[ | ]

Inversion of Control (IoC)
제어의 역전, 제어 역전, 제어 반전, 제어의 반전, 역제어[1]
  • 추상화 원칙의 한가지
  • 제어 흐름 구조가 뒤바뀌는 것
  • 실행에 필요한 객체의 생성·사용 등 제어 권한을 위임하는 것
  • 절차적 프로그래밍과 비교했을 때[2], 시스템 제어흐름이 역전되어 있는 소프트웨어 아키텍처 설계
  • 개별 목적에 따라 쓰인 코드 부분이 일반적이고 재사용가능한 라이브러리의 흐름 제어를 받는 형식의 설계
  • 예시: 서블릿(기능 정의)-컨테이너(실제 수행), 템플릿 메소드 패턴, 프레임워크
제어 반전 구조인지 여부를 프레임워크와 라이브러리를 구분하는 기준으로 삼기도 한다.

2 목적[ | ]

  • 한 태스크의 실행을 구현에서 분리한다.
  • 모든 시스템이 설계 목적에 집중하게 한다.
  • 다른 시스템이 무엇을 할지 추측하지 않아도 된다.
  • 시스템을 바꿔도 다른 시스템에 부작용을 주지 않는다.

3 예시[ | ]

public class ServerFacade {
	public Object respondToRequest(Object pRequest) {
		if (!businessLayer.validateRequest(pRequest)) {
			return null;
		}
 
		DAO.getData(pRequest);
		return aspect.convertData(pRequest);
	}
}
public class ServerFacade {
	public Object respondToRequest(Object pRequest) {
		return DAO.getData(pRequest);
	}
}

4 같이 보기[ | ]

5 참고[ | ]

  1. "제어의 역전" 5,900개, "제어 역전" 3,090개, "제어의 반전" 2,300개, "제어 반전" 1,760개
  2. 기존 절차적 프로그래밍에서는 개별적으로 개발한 코드가 그 프로그램의 목적을 표현하고, 범용적인 태스크를 수행할 경우 재사용가능한 라이브러리를 호출하는 형태임
문서 댓글 ({{ doc_comments.length }})
{{ comment.name }} {{ comment.created | snstime }}