在自己的项目中，同一个project下面有不同的view，不同的view对应不同的Model（具体实现代码），现在需要做的是A model调用B Model里面的一个方法，这个方法实现的是用ServiceAgent查询DB，这个ServiceAgent（最后了解到）是一个公用的类，最开始我是1实例化一个B model对象，调用它的方法，发现B里边这个方法用到了ServiceAgent，报错是说ServiceAgent没有实例化，（因为这个ServiceAgent初始化工作不是在BMOdel new的时候做的，而是通过import 由系统一个类调用，这个类只要new了，就会生成一个相当于工具包的东西，里边就包括这个ServiceAgent）

由此，引发了设计模式的问题。

通过大牛的引导和讲解，初步有了一个认识。

（学会vs 调试 调用堆栈）

IserviceAgent

涉及到：

工厂模式

依赖注入

反射

from2：

IDecode Decode ()

{

}

class Player(stirng type)

{

IDecode decode;

decode = Decode.decodeFile();

Type.getType();

}

1. 依赖

如果在 Class A 中，有 Class B 的实例，则称 Class A 对 Class B 有一个依赖。

public class Human {    ...    Father father;    ... public Human() { father = new Father(); } }

仔细看这段代码我们会发现存在一些问题：

(1). 如果现在要改变 father 生成方式，如需要用new Father(String name)初始化 father，需要修改 Human 代码；

(2). 如果想测试不同 Father 对象对 Human 的影响很困难，因为 father 的初始化被写死在了 Human 的构造函数中；

(3). 如果new Father()过程非常缓慢，单测时我们希望用已经初始化好的 father 对象 Mock 掉这个过程也很困难。

2. 依赖注入

上面将依赖在构造函数中直接初始化是一种 Hard init 方式，弊端在于两个类不够独立，不方便测试。我们还有另外一种 Init 方式，如下：

public class Human {    ...    Father father;    ... public Human(Father father) { this.father = father; } }

上面代码中，我们将 father 对象作为构造函数的一个参数传入。在调用 Human 的构造方法之前外部就已经初始化好了 Father 对象。像这种非自己主动初始化依赖，而通过外部来传入依赖的方式，我们就称为依赖注入。

现在我们发现上面 1 中存在的两个问题都很好解决了，简单的说依赖注入主要有两个好处：

(1). 解耦，将依赖之间解耦。

(2). 因为已经解耦，所以方便做单元测试，尤其是 Mock 测试。

3. Java 中的依赖注入

依赖注入的实现有多种途径，而在 Java 中，使用注解是最常用的。通过在字段的声明前添加 @Inject 注解进行标记，来实现依赖对象的自动注入。

public class Human {    ...    @Inject Father father; ... public Human() { } }

上面这段代码看起来很神奇：只是增加了一个注解，Father 对象就能自动注入了？这个注入过程是怎么完成的？

实质上，如果你只是写了一个 @Inject 注解，Father 并不会被自动注入。你还需要使用一个依赖注入框架，并进行简单的配置。现在 Java 语言中较流行的依赖注入框架有 、 等，而在 Android 上比较流行的有、 等。