asmbler

常见的注⼊⽅式

设计模式中常见的注⼊⽅式–依赖注⼊

最近在求职，耽搁了，对于应届⽣来讲想找个⼤数据相关的⼯作何其困难。。。

所以在填充⼀些⾃⼰不⾜之处，希望与君共勉。

⼀、依赖注⼊DI

开发过程中，如果发现客户程序依赖某个(或某类)对象，我们就通常会对他们进⾏⼀次抽象，形成抽象类、接⼝。这样，客户程序就可以摆

脱所依赖的具体类型。

那么“谁”担任这个重担呢？其实，很多时候创建型模式可以轻易的解决这个问题。但如果设计的不是具体业务逻辑，⽽是公共库/框架，

这时候很多半成品的外部类型实例会在我们的管理下执⾏，如何把这些外部类型所需的抽象类型传给他们就成了新问题。

1、控制反转–IOC

这个场景也就是常说的“控制反转”，IOC：InverofControl；框架程序与抽象类型的调⽤关系就像常说的好莱坞规则“Don’tcall

me,I’llcallyou”，即，由IOC容器帮对象找相应的依赖对象并注⼊，⽽⾮对象主动去找。

IOC容器控制了对象，主要控制了外部资源获取(不只是对象，包括⽂件等)。

IOC反转，由容器帮我们查找及注⼊依赖对象，对象是被动的接受依赖对象，所以是反转。

"依赖注⼊"的⽅式：将加⼯好的抽象类型实例“注⼊”到客户程序中。

IOC对编程的改变是在思想上，发⽣了“主从换位”的变化。

2、构造注⼊–Constructor

构造注⼊⽅式⼜称“构造⼦注⼊”、“构造函数注⼊”，这种注⼊⽅式就是在构造函数的执⾏过程中，通过Asmbler或其他机制把抽象

类型作为参数类型作为参数传递给客户类型。这种⽅式虽然相对其他⽅式有些粗糙，⽽且仅在构造过程中通过“⼀锤⼦买卖”的⽅式设置

好，但很多时候我们设计上正好就需要这种“⼀次性”的注⼊⽅式。

3、设值注⼊–Setter

设值注⼊是通过属性⽅法赋值来实现的，t(…)。

相对构造⽅式⽽⾔，设值注⼊给了客户类型后续修改的机会，它⽐较适合客户类型实例存活时间较长的情景。

4、接⼝注⼊

接⼝注⼊是将抽象类型的⼊⼝以⽅法定义在⼀个接⼝中，如果客户类型需要获得这个⽅法，就需要以实现这个接⼝的⽅式完成注⼊。

实际上接⼝注⼊有很强的侵⼊性，除了要求客户类型增加前⾯两种⽅式所需实现的代码外，还必须显式的定义⼀个新的接⼝并要求客户类

型实现它，

5、属性注⼊(C#)

在Asmbler和客户类型中选择，为了客户对象影响最⼩，我们只好在Asmbler上下功夫，因为他的职责就是负责组装。反⽽⾔之，如

果注⼊过程还需要修改客户程序，那我们就没必要去⽤“依赖注⼊”了。

但是在实际项⽬中，由于属性注⼊处理不好会导致运⾏效率低(每次实例化对象都需要映射)和对客户端的侵略性，我们要慎重使⽤。

⼆、总结

构造⽅式

他的注⼊是⼀次性的，当客户类型构造的时候就确定了

他适合⽣命期不长、在其存续期间不需要重新适配的对象

设值⽅式

⼀个很灵活的实现⽅式

对于⽣命周期较长的客户⽽⾔，可以在运⾏过程中随时注⼊

属性⽅式

作为注⼊⽅式具有⼊侵性，很⼤程度上他适于需要同时约束⼀批客户类型的情况

他本⾝实现相对复杂⼀些，但客户类型使⽤的时候⾮常⽅便–“打标签”即可

接⼝⽅式

作为注⼊⽅式具有⼊侵性，很⼤程度上他适于需要同时约束⼀批客户类型的情况

但是C#中使⽤泛型可以减少其⼊侵性

注⼊⽅式

具有⼊侵性，很⼤程度上他适于需要同时约束⼀批客户类型的情况

但是C#中使⽤泛型可以减少其⼊侵性