为什么用这么多术语来表达同一件事? IoC 和 DIP
IoC = 控制反转
DIP = 依赖关系反转原理(SOLID 中的 D)
IoC == DIP?我想是这样的,确实如此。
构建软件的世界已经如此混乱,为什么还要用这么多词来表达同样的事情呢?
(我知道DI(依赖注入),它与DIP和IoC不同)
更新:
根据答案,那么我们可以说: (DI) + (IoC) = (依赖倒置原理) ?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
控制反转是通用术语。依赖注入是一种特定类型的 IoC。
请参阅控制容器反转和依赖注入模式。
依赖倒置原则是一个指南,而其他术语是对技术的描述。 (IoC 也可以用来描述原理,因此这可能会令人困惑。)
用在句子中:
更新:
我不认为(DI) + (IoC) = (依赖倒置原则)是准确的。这就像说(苹果)+(食物)=(良好的营养)。每个术语都有特定的含义。
Inversion of Control is the generic term. Dependency Injection is a specific type of IoC.
See Inversion of Control Containers and the Dependency Injection pattern.
The Dependency Inversion Principle is a guideline, while the other terms are descriptive of techniques. (IoC can be used to describe a principle as well, so this can be confusing.)
Used in a sentence:
Update:
I do not feel that (DI) + (IoC) = (Dependency Inversion Principle) is accurate. That's like saying (Apple) + (Food) = (Good Nutrition). Each term has a specific meaning.
我认为你不会在这个问题上得到权威的答案,因为“IoC”这个术语有点过多,说“IoC 的真正含义是……”有点迂腐。但无论如何我都会分享我的观点:)
依赖倒置是关于依赖于抽象。考虑一个依赖于
IStringWriter
的HelloWorld
类和一个实现类ConsoleStringWriter
。控制反转是指框架/基础设施调用应用程序代码,而不是相反。例如,当用户关闭 WPF 应用程序时,您不会调用框架,它会引发一个您可以订阅的事件。
它们经常组合在一起。例如,Hibernate 依赖于 其Interceptor接口以实现IoC。从拦截器的角度来看,控制是颠倒的——Hibernate 调用拦截器。您随处可见的另一个示例是
IHandle
,其中 T 是事件、命令或消息 - 基础结构在正确的时间调用处理程序。这很令人困惑,因为我们称它们为“IoC 容器”,但您可以在不进行 IoC 的情况下进行 DI。如果将
ConsoleStringWriter
注入到HelloWorld
中,我实际上并不认为这是 IoC,因为没有“框架”或“基础设施”。但这是因为 Hello World 很琐碎 - 随着应用程序变得更加复杂,对 IoC 的需求也会增加。另请参阅此问题和接受的答案。
I don't think you're going to get an authoritative answer on this one because the term "IoC" is kind of overloaded and to say "the one true meaning of IoC is..." is kind of pedantic. But I'll share my opinion anyway :)
Dependency Inversion is about depending on an abstraction. Consider a
HelloWorld
class that depends on anIStringWriter
, and an implementation classConsoleStringWriter
.Inversion of Control is when the framework/infrastructure invokes application code, rather than the other way around. For example, when a user closes a WPF app, you don't call the framework, it raises an event that you can subscribe to.
They are often combined. For example, Hibernate depends on the abstraction defined by its Interceptor interface in order to implement IoC. From an Interceptor's point of view, control is inverted - Hibernate calls the Interceptor. Another example you see all over is
IHandle<T>
where T is an Event or a Command or a Message - the infrastructure calls the handler at the right time.Its confusing because we call them "IoC containers", but you can do DI without doing IoC. If you inject a
ConsoleStringWriter
into aHelloWorld
I don't really think of this as IoC because there is no "framework" or "infrastructure". But that's because Hello World is trivial - as an application becomes more complex the need for IoC increases.See also this question and accepted answer.