从一个任务起初讲
某天，公司领导找到开发人士，说要支付一个微信支付宝的收费明细获取功效，我们把这个任务作为一个案例举办验证。
第一步：设计
案例精简：把任务指派给开发人士完成。本句话中，有五个名词：“任务”和“开发人士”，所以大家考虑设计四个目的(任务和开发人士)。
开发人士对象：
package DependencyInjectionDemo;
public class Javaer {
private String name;
public Javaer(String name) {
this.name = name;
}
public void setName(String name) {
this.name = name;
}
public void WriteCode() {
System.out.println(this.name + " writting java code...");
}
}
任务目的：
package DependencyInjectionDemo;
public class NewTask {
private String name;
private Javaer javaer;
public NewTask(String name) {
this.name = name;
this.javaer = new Javaer("张三");
}
public void Start() {
System.out.println(this.name + " started ..");
this.javaer.WriteCode();
}
}
场景类：
package DependencyInjectionDemo;
public class DependencyInjectionDemo {
public static void main(String[] args) {
NewTask task = new NewTask("开发微信支付宝收款明细获取工具");
task.Start();
}
}
运作结果：
开发微信支付宝收款明细获取工具 started ..
张三 writting java code...
目前让我们来分析一下以此企划存在的题材。
- 假诺不追求复用和耦合，只是暂时完成任务，这么写倒也无可厚非;
- 若果再有其它任务指派给任何开发人员，我们需要去代码内部修改编码;
- 设若有很向往你的同事需要复用你的实现，你无法打包成jar文件给他径直用，因为她无法从jar文件外部修改任务和开发人士；
就此，我们应当让用户来打发开发人员，立异一下：
package DependencyInjectionDemo;
public class NewTask {
private String name;
private Javaer javaer;
public NewTask(String name) {
this.name = name;
//this.javaer = new Javaer("张三"); 删了啦
}
public void SetJavaer(Javaer javaer) {
this.Javaer = javaer;
}
public void Start() {
System.out.println(this.name + " started ..");
this.javaer.WriteCode();
}
}
场景类也要做一下修改：
package DependencyInjectionDemo;
public class DependencyInjectionDemo {
public static void main(String[] args) {
NewTask task = new NewTask("开发微信支付宝收款明细获取工具");
task.SetJavaer(new Javaer("张三")); //加入这句
task.Start();
}
}
出口和前边的Demo是如出一辙的：
开发微信支付宝收款明细获取工具 started ..
张三 writting java code...
最近，我们了然了一个事实，完成任务急需依靠特定的开发人员（NewTask类依赖Javaer类），开头时，NewTask类在构造时绑定开发人士，现在这种借助可以在采取时按需要展开绑定。
这就是凭借注入
在下面的案例中，大家是经过Setter举行注入的，另外一种常用的流入形式是由此构造方法举行注入：
public NewTask(String name, Javaer javaer) {
this.name = name;
this.javaer = javaer; //构造方法中进行注入
}
此地联想一下，任务履行期间，任务执行者（本例中是张三）生病了，那么就需要此外配置一名开发人士继续任务的施行，怎么做吧？这一个时候应该考虑的是Javaer这一个目的的祥和，要是开发人员这么些目标稳定性万分高，我们可以设想在NewTask的构造方法中举办注入，因为开发人士这个目的特别安静，不会并发中途换帅的情事，但实情并非如此，张三生病了，就得同意不停顿任务的情形下，重新指派另一名开发人士继续展开开发，很明朗，在这么些情景中，我们相应使用Setter注入，不需要再行New一个NewTask（也就是任务再次起头），间接使用Setter更换开发人员即可。
那里还有一种注入形式是部署文件注入，这就要求注入的目标稳定性相当高，甚至高到超越服务的生命周期（比如数据库连接）。
其次步：需求挖掘
咱俩掌握，一个付出集团往往是多种开发语言并存的，有些任务切合用Java来成功，有些符合用C#，还有些任务切合用Python，现在题材来了，这多少个NewTask类库的使用者发现：任务只可以指派给Javaer。
于是为了更好的复用，大家的需要应该成为：任务既能指派给Javaer，也能打发给Pythoner和C夏普er，以及另外任何将来或者进入的开销语言。
很自然的，我想到了使用接口:
package DependencyInjectionDemo;
public interface Coder {
void WriteCode();
}
修改原来的Javaer,实现Coder接口：
package DependencyInjectionDemo;
public class Javaer implements Coder {
private String name;
public Javaer(String name) {
this.name = name;
}
public void setName(String name) {
this.name = name;
}
public void WriteCode() {
System.out.println(this.name + " writting java code...");
}
}
Python开发人员实现Coder接口：
package DependencyInjectionDemo;
public class Pythoner implements Coder{
private String name;
public Pythoner(String name) {
this.name = name;
}
@Override
public void WriteCode() {
System.out.println(this.name + " writting python code...");
}
}
C# 开发人士实现Coder接口：
package DependencyInjectionDemo;
public class CSharper implements Coder {
private String name;
public CSharper(String name) {
this.name = name;
}
@Override
public void WriteCode() {
System.out.println(this.name + " writting c# code...");
}
}
修改任务类中的Javaer为Coder：
public class NewTask {
private String name;
private Coder coder;
public NewTask(String name) {
this.name = name;
}
public void SetCoder(Coder coder) {
this.coder= coder;
}
public void Start() {
System.out.println(this.name + " started ..");
this.coder.WriteCode();
}
}
修改场景类：
package DependencyInjectionDemo;
public class DependencyInjectionDemo {
public static void main(String[] args) {
NewTask task = new NewTask("开发微信支付宝收款明细获取工具");
task.SetCoder(new Javaer("张三"));
// 都是Coder，允许注入
// task.SetCoder(new Pythoner("李四"));
// task.SetCoder(new CSharper("王五"));
task.Start();
}
}
目前，我们得以派出任务给pythoner，CSharper和Javaer了，出席以后进入了Ruby或者Go语言开发人士，类库的使用者只需要实现Coder接口，就足以把任务指派给新来的开发人士了，不需要修改NewTask代码，实现了低耦合和可扩大性。
在讲下边的情节前边，我们先来熟识一个名词：支配反转，五个字，拆成六个词，一个是决定，一个是反转。结合地点的例子，大家的NewTask先河的时候依赖开发人员，其在其间主动创设了开发人员对象，后来我们发现这么造成了强依赖，于是就把NewTask的积极向上成立开发人士这么些操作裁撤了，修改成了在表面实现开发人士实例并传到到NewTask内部，NewTask现在只可以被动的收受我们成立的开发人士对象，从积极到被动，控制落实了反转。
概念
除外倚重注入(Dependency Injection,
简称DI)，还有此外一种办法是“倚重查找（Dependency Locate）”，
场景类需要服务类时，从一个到手点主动获取指定的服务类。这种措施变被动接受注入为积极获取，使得场景类在急需时积极赢得服务类，如大家向一个统管全局的Factory传入一个字符串，Factory再次回到给自己一个相应服务类的实例。
但是，不论选择简单工厂（Simple Factory）仍然抽象工厂（Abstract
Factory），都避免不了判断服务类类型或工厂类型，这样系统中总要有一个地点存在不吻合OCP的if…else或switch…case结构，这种缺陷是Simple
Factory和Abstract
Factory以及凭借获取自我无法清除的，而在某些协助反射的言语中（如Java和C#），通过将反射机制的引入彻底解决了这一个题目。
反射与依靠注入
地点的例证中，假使我们再扩展一个语言的分层（如Go）而且接纳了工厂形式（简单或抽象工厂），大家需要贯彻Coder接口，即便符合开闭原则（对扩充开放，对修改关闭），但最终，我们仍旧要回到工厂方法内部，去充实一个swith或ifelse分支，以完美大家的论断，这就破坏了开闭原则。依赖注入我是未曾力量解决这么些题目的，但语言本身的反光机制（Reflection）却能从根本上解决那么些题材。
近日的题目是，最终我们找到的这个目的，如故需要通过“new”操作来实例化，那么，我们怎么通过不改动代码的章程，“new”出一个新的实例呢？
来试着实现一下：
package DependencyInjectionDemo;
import java.lang.reflect.Constructor;
import java.lang.reflect.InvocationTargetException;
public class DependencyInjectionDemo {
private static String taskName; //任务
private static String coderName; //语言
private static String devName; //开发人员
public static void main(String[] args) throws ClassNotFoundException, NoSuchMethodException, InvocationTargetException, InstantiationException, IllegalAccessException {
/*现在我可以把这些写到配置文件中了*/
taskName = "新任务名称";
coderName = "Pythoner";
devName = "小明";
NewTask task = new NewTask(taskName);
Coder coder = getCoder(coderName, devName);
task.SetCoder(coder);
/* 以前这么写 */
// task.SetCoder(new Pythoner("李四"));
// task.SetCoder(new CSharper("王五"));
task.Start();
}
/**
* 根据类名获取类实例
* @param coderName
* @param name
* @return 类的实例对象
* @throws ClassNotFoundException
* @throws NoSuchMethodException
* @throws IllegalAccessException
* @throws InvocationTargetException
* @throws InstantiationException
*/
public static Coder getCoder(String coderName, String name) throws ClassNotFoundException, NoSuchMethodException, IllegalAccessException, InvocationTargetException, InstantiationException {
Constructor c = Class.forName("DependencyInjectionDemo."+coderName).getConstructor(String.class);
Coder coder = (Coder)c.newInstance(new Object[] {name});
return coder;
}
}
输出：
新任务名称 started ..
小明 writting python code...
如上代码，实现了一个基于类名获取实例的getCoder方法，该办法有多少个参数，一个是类名，另一个是Coder的布局参数name。在气象操作中，分别定义了职责名称，语言，开发人员五个变量，现在一旦那一个变量完全是从配置文件中读取的，那么，当我们随后扩大新的语言，扩充新的开发人士时，只需要新增添一个Coder接口的贯彻，然后修改配置文件即可。真正落实了OCP原则。怎样？是不是感到自己很牛逼？
以下为摘录内容，来源:看重注入这一个事情
IoC Container
说到依靠注入的话，就务须提到IoC
Container(IoC容器)，那么究竟怎么着是IoC容器？我们仍然先来看望它的面世背景。
俺们知道，软件开发领域有句出名的判定：不要再度发明轮子！因为软件开发讲求复用，所以，对于利用频繁的要求，总是有人设计各个通用框架和类库以减轻人们的开销负担。例如，数据持久化是分外频繁的需求，于是各样ORM框架应运而生；再如，对MVC的要求催生了Struts等一批用来贯彻MVC的框架。
乘势面向对象分析与统筹的迈入和老成，OOA&D被进一步广泛应用于各样档次中，可是，我们知道，用OO就不可以毫无多态性，用多态性就不容许并非看重注入，所以，依赖注入变成了分外频繁的需要，而一旦一切手工完成，不但负责太重，而且还易于失误。再增长反射机制的表明，于是，自然有人初阶计划开发各类用于倚重注入的专用框架。这个特别用于落实依靠注入效能的零部件或框架，就是IoC
Container。
从这点看，IoC
Container的出现有其历史必然性。如今，最出名的IoC也许就是Java平台上的Spring框架的IoC组件，而.NET平台上也有Spring.NET和Unity等。
IoC Container 的分类
眼前已经钻探了两种依赖注入格局，不过，想通过措施对IoC
Container举办分拣很不便，因为明天IoC
Container都统筹很周密，几乎襄助具备倚重注入形式。可是，依据不同框架的特征和惯用法，仍旧得以讲IoC
Container分为三个大类。
-
重量级IoC Container
所谓重量级IoC
Container，是指一般用外表配置文件（一般是XML）作为看重源，并托管整个序列依次类的实例化的IoC
Container。这种IoC
Container，一般是承前启后了一切系列几乎所有多态性的借助注入工作，并承接了所有服务类的实例化工作，而且这些实例化看重于一个表面配置文件，这种IoC
Container，很像经过一个文书，定义整个系统多态结构，视野宏大，想要很好了解这种IoC
Container，需要自然的架构设计能力和增长的实践经验。Spring和Spring.NET是重量级IoC Container的例证。一般的话，那种IoC
Container稳定性有余而活性不足，适合举办低活多态性的依靠注入。 -
轻量级IoC Container
再有一种IoC
Container，一般不依靠外部配置文件，而根本利用传参的Setter或Construtor注入，这种IoC
Container叫做轻量级IoC
Container。这种框架很灵敏，使用方便，但往往不安静，而且依赖点都是先后中的字符串参数，所以，不合乎需要大规模替换和相持平静的低活多态性，而对于高活多态性，有很好的功用。XML，Unity是一个压倒元白的轻量级IoC Container。