[spring][读书笔记]一些关于依赖注入的理解。

本文首发于本人微博。这里做备份整理。
阅读完spring in action 第四版 前半部的一些总结。
一些关于 DI 的理解。
什么是依赖注入呢？其实这个名称是英文直译，到是不存在什么因为翻译不好所以理解不对的情况。（耦合这个词或许令人难以理解。）
去年尝试看了，今年上半年尝试看了，可能对于面向对象编程的理解不到家，当时一直是无法很好的理解。
今天又认真看了，所以干脆记下来自己的理解吧。
肯定会有一些问题，也望懂行的家人们补充。
其实就是一个关于主动权的问题。
设想我们设计一个程序，大的整体实际上是有无数的小的模块构成的。其中包含无数个方法、函数。
想要一个程序的逻辑是贯通的，那么这些个方法、函数肯定都不是一座“孤岛”。
而连接这些方法、函数的方式有很多种，不存在什么对错，因为代码不报错就是第一步成功对吧？但更加重要的还是，一份代码更新、维护起来的费劲程度。
不好的连接的方式会导致我们需要花费更多的时间去进行维护。
因为方法之间的联系太过紧密了，我们无法很好的保证修改这里的代码，别的地方的代码不会崩掉。
这样的程序我们称之为耦合性强的程序。牵一发而动全身，对程序员维护程序而言是一种极其痛苦的体验。
想要减少代码维护的难度，我们需要对程序进行重新的设计了，至少说明先前多个方法之间的连接方式是不太合理的。
想要降低维护难度，其实只需要让方法与方法之间的连接不那么紧不就好了？但是这肯定不是绝对的，因为完全没有联系的方法是无法组成一个程序的。
因此我们要做的只能是减少联系，而不是完全不联系。
这就是所谓的降低耦合度。
那么要怎么做到降低耦合度呢？
这里来看两份相对简单的代码吧。（是spring in action 第四版的例子，此书的第5版写的不太好，这里推荐第4版）

例子

由我来讲解关于这个代码的故事吧。
现在我们要制作一款游戏，是关于中世纪的冒险游戏。
你现在拥有骑士这一角色，你可以为给骑士发布任务。骑士在执行任务之前要先汇报自己开始了任务。

那么，我现在要创建一个能够执行营救少女这项任务的骑士。
那么这里有两份代码。分别是 p1 和 p2 。
我们首先来阅读p1：
我是一个专门接收营救少女任务的骑士。
我可以创建关于营救少女的任务。
也可以宣布自己开始任务了。

似乎挺对的，没发现什么问题。
我又改变了需求，我希望有一位骑士可以帮我解决其他的问题，比如除恶龙。
那这样的话，岂不是要再生成一个专门用来除恶龙的骑士？
嗯，这么想也没错。但是代码是否要写很多？而且不觉得很奇怪么，只要任务不同就要迭代一次代码，更新出一位新的骑士，这样下来，代码维护起来相当的麻烦。

那么我们要怎么修改这份代码，让它能够扛住更多的任务？
一起来看看p2吧。
我是一位骑士，我接受并响应任务。

没错，现在我们无所谓到底是什么样的骑士，我们也不需要在意到底什么什么样子的任务了，因为我们要做的只有，接收任务并响应“我开始任务了！”就够了。

至于到底是什么任务？我不需要知道，为我提供就好了，我自己接收。
这样的代码，适合各种情况（万能的骑士至少比 p1 这种只能做哪件事的骑士靠谱吧。）

总结

因此依赖注入（DI）本质其实就是，创造出方法与方法之间连接较少的代码。（降低耦合度）
而最常用的操作便是：
主动权不在我，你给我提供现成的就好了！我需要这东西的时候直接用就好了，而不是我需要这东西的时候，我还得自己现把它做出来！

本作品采用《CC 协议》，转载必须注明作者和本文链接