依赖注入有什么好的比喻？
在对非 DI 系统进行编程时，我经常想到的一个比喻是“一个人在玩他/她的玩具”。人是一个对象，人的玩具是对象创建、存储、初始化和操作的任何东西。当玩具达到某种状态时，它们可以发出事件，但它们对使用它们的人一无所知；它们只是带有控制开关的小黑匣子，构成了它们的接口。人们可以监听玩具发出的事件并通过操纵其界面做出响应。这个人可以用他/她的玩具做任何他/她想做的事，但他/她可能不应该去干涉他们的内部，因为它们可能会破裂。
DI 对我的比喻造成的严重破坏是，它将玩具变成了有意识的生物，知道它们的主人，即使用它们的人。玩具可以操纵这个人，但这个人对它们的工作原理一无所知，甚至不关心。这个人只是拥有玩具并期望玩具能够操纵他/她以使玩具自己满意。
搞什么？？听起来很可怕！！
他们用来思考 DI 系统如何工作的一个好的心理比喻是什么？
A metaphor that stuck with me when programming non-DI systems is "a person playing with his/her toys". A person being an object and the person's toys being anything that object creates, stores, initializes, and manipulates. The toys can dispatch events when they reach a certain state, but they know nothing about the person using them; they're just little black boxes with control switches that make up their interfaces. The person can listen for events from the toys and respond by manipulating their interfaces. The person can do whatever he/she wants with his/her toys, but he/she probably shouldn't go meddling with their innards because they might break.
The havoc that DI wreaks upon my metaphor is that it turns the toys into conscious beings that know their owner, the person using them. The toys can manipulate this person, but the person knows nothing of how they work and doesn't even care. The person just owns the toys and expects the toys to manipulate him/her to the toys' own satisfaction.
WTF?? That sounds horrible!!
What is a good mental metaphor they've been using to think of how DI systems work?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
想想一位绅士和他的管家。管家（DI 框架）根据需要向绅士提供他需要的任何服务（外部依赖）（有些服务，如早晨的咖啡，在“初始化”时提供:-)）；绅士（你的班级）只是消费服务，并不关心它们来自哪里，只要它们满足他的要求（实现某些接口）即可。
或者如果你想让它更接近你的比喻，你的类是孩子，DI 框架是妈妈，玩具是其他组件。孩子不在乎玩具从哪里来，只要她能按照自己喜欢的方式玩就行了。
Think a gentleman and his butler. The butler (the DI framework) provides to the gentleman any services (external dependencies) he needs upon demand (and some, like the morning coffee, upon "initialization" :-)); the gentleman (your class) just consumes the services and does not care where they come from, as long as they meet his requirements (implement certain interface).
Or if you want to make it closer to your metaphor, your class is the kid, the DI framework is the mom, and the toys are the other components. The kid doesn't care where the toys come from, as long as she can play the way she wants with them.
SOLID 励志图片 是一个很好的来源。
The SOLID motivational images are a good source.
从我的角度来看，就你的比喻而言，DI 和非 DI 之间的区别在于非 DI 系统，每个人都制作自己的玩具 - 他们必须知道如何制作它们，并且只能使用他们制作的玩具。通过 DI，人们可以使用给予他们的玩具。他们不知道如何制作玩具，但只要知道玩具的行为方式，他们就可以玩任何给他们的玩具。
From my perspective the difference between DI and non-DI with respect to your metaphor is with non-DI systems, each person makes their own toys -- they have to know how to make them and they can only use the toys they make. With DI, the person uses the toys they are given. They don't know how to make them, but they can play with any toys they are given as long as they know how the toy behaves.
乐高积木。
将乐高积木视为一种软件组件，它公开一个或多个接口（顶部的小凸起）并具有一个或多个设置器或构造函数参数（底部的孔）。
当您购买一盒乐高积木时，这些积木并没有预先组装（硬连线）。它们是独立的组件。然后，通过将接口（凸块）连接到设置器/构造器（孔）来组装它们（接线）。每个块都不直接了解其他块。组装它们还需要块以外的东西——那就是你（或 main() 或 Spring 配置文件等）。
我知道......这有点崩溃，因为乐高积木很大程度上有一个统一的界面 - 但它对我有用:-)
Legos.
Think of a Lego block as a software component that exposes one or more interfaces (the little bumps on top) and has one or more setters or constructor arguments (the holes on the bottom).
When you buy a box of Legos, the blocks don't come preassembled (hard-wired). They are independent components. You then assemble them (wire them) by connecting interfaces (bumps) to setters/constructors (holes). Each block knows nothing about the other blocks directly. Something other than the block is required to assemble them - that is you (or main() or a Spring config file, etc.).
I know... this breaks down a bit because Legos largely have a uniform interface - but it works for me :-)
我用的是电脑系统。您有一个系统块，并且您（DI）将监视器、键盘和鼠标连接到它。系统块只知道显示器是 DVI 设备，但不关心它到底是哪台显示器。它知道如何使用 USB 鼠标，但不知道也不关心它是光学鼠标还是滚珠鼠标。
您 - DI 框架。
系统块 - 是正在服务的系统。
监视器/鼠标/键盘 - DI（您）向系统块提供的服务。
I use computer system. You have a system block, and you (a DI) connect to it a monitor, a keyboard and a mouse. The system block only knows that a monitor is a DVI device, but cares not which monitor precisely it is. It knows how to use USB-mouse, but does not know or care weather it is an optical or a ball-rolling mouse.
You - the DI framework.
System block - is the system being served.
Monitor/mouse/keyboard - services provided by DI (you) to the system block.
玩具没有意识。他们只是让人们把一些绳子绑在钩子上，当某些事情发生时，钩子转动，绳子被拉动，所以人们知道发生了什么事。
The toys aren't conscious. They just let the person tie bits of string to hooks, and when certain things happen, the hooks turn and the string gets pulled on, so the person knows something happened.
我被告知将其与 CD 播放器联系起来的一个 DI 隐喻。播放器并不关心你放入什么CD；然而，您插入播放器的每张 CD 根据播放器的需要提供不同的功能。
One DI metaphor that I was told was to relate it to was that of a CD player. The player doesn't care what CD you put in; however, each CD you inject into the player provides different functionality based on what the player requires from it.
这都是关于武士和武器的。尝试查看 ninject：http://ninject.org/。转到“参观道场”角色，了解一个有趣的隐喻。不确定这是否是您的意思，但它仍然很有创意。
It's all about Samurais and weapons. Try checking out ninject: http://ninject.org/. Go to the "Visit the Dojo" character for an interesting metaphor. Not sure if this is what you meant but it's creative nonetheless.