Inversion of control
来源:互联网 发布:centos 7搭建html 编辑:程序博客网 时间:2024/06/06 16:53
Inversion of control
From Wikipedia, the free encyclopedia
Inversion of control, or IoC, is an abstract principle describing an aspect of some software architecture designs in which the flow of control of a system is inverted in comparison to procedural programming.
In traditional programming the flow is controlled by a central piece of code. Using Inversion of Control this central control as a design principle is left behind. Although the caller will eventually get its answer, how and when is out of control of the caller. It is the callee who decides how and when to answer. The principle of Inversion of Control is also known as the Hollywood Principle. Inversion of Control as a design guideline serves the following purposes:
- There is a decoupling of the execution of a certain task from implementation.
- Every system can focus on what it is designed for.
- Every system does not make assumptions about what other systems do or should do.
- Replacing systems will have no side effect on other systems.
Contents
[hide]- 1 Example
- 2 Background
- 3 Implementation techniques
- 4 Advantages and disadvantages of inversion of control
- 5 References
- 6 See also
[edit] Example
public class ServerFacade{ public Object respondToRequest(Object pRequest) { if(businessLayer.validateRequest(pRequest)) { DAO.getData(pRequest); return Aspect.convertData(pRequest); } else { return null; } }}
This basic outline gives an example of code following the IoC methodology. Important however is that in the serverFacade a lot of assumptions are made about the data returned by the DAO object. Although all these assumptions might be valid at some time, they couple the implementation of the serverFacade to the DAO implementation. Designing the application in the thought of Inversion of Control would hand over the control completely to the DAO object. The code would then become
public class ServerFacade{ public Object respondToRequest(Object pRequest) { return DAO.getData(pRequest); }}
It does not make any assumption about what is happening next on both sides of the exchange. The caller and the callee should know, not the serverFacade. This is the next important effect of Inversion of Control. The serverFacade is doing solely the task for which it is designed, namely connecting systems.
[edit] Background
Inversion of Control is not a new term in computer science. According to Martin Fowler[1] the etymology of the phrase dates back to 1988. It is debatable if it is a new architectural principle. It is very comparable to the technique to create abstraction by layering. Inversion of Control however created hype as something new. It definitely raised the awareness for this architectural principle and gave architects a proper guideline to improve their work. Doing that it served its job well. In the world of Java, if not others, Inversion of Control has created its own namespace. Compared to 'abstraction by layering' it is a more specific term, which at the same time describes its purposes in a more concrete way. The term itself is not that abstract to say. It is to prefer when architectural terms would not be computer language specific.
It is still discussed if inversion of control is a design pattern, an architectural principle, or both. In an article by Shivprasad Koirala[2] Inversion of Control is presented together with Dependency Injection as a design pattern. It is a practical example of the first five techniques mentioned. He also shows that Dependency Injection might be a design pattern, whereas Inversion of Control is implemented using Dependency Injection. In an article by Mani Malarvannan[3] Inversion of Control is presented as a design pattern using contextualized lookup. The use of a service locator is considered using the same design pattern.
In an article by Robert C. Martin[4] the dependency inversion principle and abstraction by layering come together. His reason to use the term inversion is in comparison with traditional software development methods. He describes the uncoupling of services by the abstraction of layers, when he is talking about dependency inversion. The principle is used to find out where system borders are in the design of the abstraction layers.
Inversion of Control is highly associated with dependency injection and the dependency inversion principle. Dependency injection is the main method to implement Inversion of Control.
[edit] Implementation techniques
Implementation techniques are influenced by the computer language used. Next is an overview of techniques how to implement IoC ordered by language. In Java there are six basic techniques to implement inversion of control. These are:
- using a factory pattern,
- using a service locator,
- using a constructor injection,
- using a setter injection,
- using an interface injection, and
- contextualized lookup.
In an original article of Martin Fowler[5] the first five different techniques are discussed. In a description about Inversion of Control types[6] the last one is mentioned. Often the contextualized lookup will be accomplished using a service locator. More important than the applied technique however is the optimization of the purposes. Inversion of Control is not restricted to these techniques, but serves these forementioned purposes.
[edit] Advantages and disadvantages of inversion of control
Inversion of Control has the same advantages and disadvantages as any type of abstraction. It roughly simplifies the building of specific tasks on one hand and makes the orchestration of applications more complex on the other.[citation needed]
Taking the code in the article of Robert C. Martin[4] as an example. There are in the end five classes needed to switch a lamp after pressing a button. In procedural programming this could have been implemented using one method. Inversion of Control has the advantage and power to uncouple implementations from each other, but the orchestration is more complex. Where the danger in procedural programming is to end with spaghetti code, the danger when using Inversion of Control is ending with macaroni code[citation needed] (in the extreme: methods with only one line of code that merely act as gateway to the next layer).
- Inversion of Control
- Inversion of control
- Inversion of Control
- Inversion of Control
- Inversion of Control
- Ioc(Inversion of Control)
- 设计模式:Inversion of Control (Dependency Inversion)
- Inversion of Control (控制倒置)
- Inversion of Control 控制倒置
- inversion of control(控制反转)
- 关于IOC(Inversion of Control)
- Inversion of control (控制反转)
- Spring ioc(Inversion of Control )
- 3. Inversion of Control (IoC)
- 解析Inversion of control和Dependency Injection
- IoC(Inversion of Control)反转控制
- 控制反转(Ioc=Inversion of Control)
- 控制反转(Inversion of Control)
- 使用递归调用求数组的最大值,了解递归的栈调用以及递归函数的具体执行过程
- 关于为什么程序员“干不长久”
- Undefined symbol: 'CEikLabel::CEikLabel(void)
- 在arcgis中由等高线生成dem的步骤
- Java异常设计原则
- Inversion of control
- 批处理去掉所有目录的隐藏系统只读属性
- centos yum php5.2.x repo安装方法
- Session与Cookie的区别
- 基于Annotation的Struts2.0+Hibernate3.3+Spring2.5整合开发 (1)
- 风之伤逝
- sql2005 odbc建立连接容易出错的地方
- 对DNS应答报文的解析及简单处理代码
- 面向过程VS面向对象之我见