IoC Introduction
2004-12-03 00:28
190 查看
Introduction to IoC
See IoC example on why to use IoC with an example in Pico. Changes to this example to use it with Spring are in Spring example.Example for conventional lookup (e.g. with JNDI in EJBs):[/i]
public class Foo { public Foo() { } public String service() { return BarManager.lookup("myBar").doSomething(); } }
Example of IoC 3:[/i]
public class Foo { private Bar bar; public Foo(Bar bar) { this.bar = bar; } public String service() { return bar.doSomething(); } }
Types
Method-based (M)[/i] IoC : Pass dependent components to the component with every method callInterface-based (I)[/i] IoC (Type 1): Uses Interfaces like Serviceable, Configurable etc. for declaring dependencies
Setter-based (S)[/i] IoC (Type 2): Uses setters for setting dependent components
Constructor-based (C)[/i] IoC (Type 3): Uses constructors for declaring dependencies
Example Method based IoC :[/i]
public class Foo { public Foo() { } public String service(Bar bar) { return bar.doSomething(); } }
Example of IoC 1:[/i]
public class Foo implements Barable { public Foo() { } public void doBar(BarManager bm) { Bar bar = (Bar) bm.lookup("myBar"); bar.service(); } }
Example of IoC 2:[/i]
public class Foo { private Bar bar; public Foo() { } public void setBar(Bar bar) { this.bar=bar; } public String service() { return bar.doSomething(); } }
Disadvantages
You declare your dependencies, some magic happens and they are resolved. Magic makes source code harder to understand than lookups (because they are implicit not explicit)Advantages
If you use singletons or lookups your unit tests are difficult to write (Just see all those special J2EE unit frameworks). With lookups you usually have to implement a registry that supplies MockObjects. If your lookups are static methods replacing them with MockObjects is even more difficult. With lookups you might have to do this (if you can control the registry, which most of the time is impossible or at least hard to do[/i]):// What if you can't change the created class // in your singleton or registry? Do you need to rewrite // the whole JNDI lookup classes? BarManager.setBarClass("myBar", MockBar.class);Foo foo = new Foo(); assertEquals("ping", foo.service());
IoC is more JUnit test friendly than lookups. With Type-3 IoC you just do:
Foo foo = new Foo(new MockBar()); assertEquals("ping", foo.service());
With Type-2 this would be:
Foo foo = new Foo(); foo.setBar(new MockBar()); assertEquals("ping", foo.service());
No external dependecies. You can develop and test your components in the enviroment you like, you do not need to use a special deployment enviroment for your components during development (like with JNDI / EJB)
Easier to reuse and easy exchangeable between different IoC containers. Either implement simple wrappers or add setters and interfaces to use components from e.g. Pico in Avalon and Spring
Advantages of Type-2
Beans are well understood by Java developers, beans exist in most projectsMore easily satisfies optional dependencies
Disadvantages of Type-2
Dependencies can be seen from the code. What are dependencies and what are normal setters and getters? Additional setters and getters make code more noisyNeeds some XML (or other) meta data which makes understanding code more difficult from looking at it
Advantages of Type-3
Stronger contract between componentsComponents cannot exist in "limbo" state between creation and when they can be used. This is more defensive
Disadvantages of Type-3
You may need your constructors (I do not :-)Inheritance can become more difficult.
相关文章推荐
- Solaris+Redhat+Windows共存
- API版本的TrimNull函数
- API版本的TrimNull函数
- IoC模式的类型及其实现
- Solaris 10 的困惑与喜悦
- 中国DNN当前的运作方式
- [导入]Linux内核飞行十二年[转贴]
- 2004-11-30 Sybase EBF 12150: 12.5.3 IR
- 保护卡自动改IP程序实现方法(根据现有保护卡的种种迹象猜的)
- 理解网页中各种不常用的
- 电灯泡杂谈
- property procedures offers a few advantages
- [转载]大学生创业:一个硬件网站站长自述创业经历
- 到神农架看看吧
- HTML文档中小meta的大作用
- 一份不错的性能测试计划模版,可惜是英文的。(转自QACity)
- 好像知道了什么是喝花酒
- 网页制作小技巧
- Community Server 1.0 Beta安装使用记录(二)
- SQL注入天书—ASP注入漏洞全接触