天道酬勤,学无止境

Antipatterns of IoC container usage. Why IoC containers are so complex and used so "fancy" way?

I'm seriously start thinking that usage of IoC container provokes to create overdesigned solutions (at least it provokes me to try to use various unnecessary features:).

It's the time to synchronize my "IoC" antipatterns list with community one's..

My short experience tell that it is absolutely enough to call Resolve method once per application at startup to resolve some infrastructure singletons and initiate with them "transient object's factory" that could produce new "smaller life time grain factories" . Even to make those factories thread safe (e.g. create one instance per thread) is so easy to achieve by adding 10 code lines into factory... Still those factories are much more simpler then "library's integration with IoC tool". Interception? Just create your own wrappers... Life time managers / dependency strategies/ parent containers? Call the Resolve only once at bootstrapper and you won't think about that.

Could you help me to understand why developers call Resolve several times on different application layers (by passing container or by passing delegate to container) and then have a lot of things to think about? I really worry that I miss something.

标签

评论

When it was not clear to me how to use an IoC container, I decided to stop using it, because I thought was just an overcomplication over the simple dependency injection.

It is true though that even without IoC is possible to fall in the over-injection cases. A while ago I read some posts from the author of ninject that opened my mind.

As you already know the injector should be used only inside the context root. However, in order to avoid over-injections, I decided to introduce an exception of the rule for injected factories.

In my framework, factories (and only factories) can use the injector container. Factories are binded in the container in the context root and therefore can be injected. Factories become valid dependencies and are used to create new objects inside other objects, using the injector container to facilitate dependencies injection.

Some kind of IoC are anti-patterns or may be in some cases. For example the service locator antipattern. But if you are using constructor injection at the beginning of your application - and only there - then it should not lead to an anti-pattern.

Injecting a DI container interface in a class is a wrong use of constructor injection. If DI is not part of the business logic of your class it should not know or depend on DI container nor should it depend on IKitchen. It's only fine to inject your DI container in some kind of helper or service working in conjunction with your dependency injection container, because it's purpose is to work with or around DI container. The examples in the links you give are misuse of IoC. It does not mean that IoC in general is an anti-pattern.

I think the correct question would be "Can constructor injection be an anti-pattern?". So far I've never faced any situation or seen any example where it was so I would say "no", until I face such a situation.

Read This

Clearly something wrong. New library should not bring additional complex code.

I've found somebody who possibly could understand me :)

Constructor over-injection anti-pattern

Other antipattern in my eyes is pushing the initialization of container "deeper" then actual bootsrapper.

For example Unity and WCF recommendations

Bootstrapper in wcf app is the service constructor, then just put container initialization to constructor. I do not understand reasons to recommend to go for programming wcf sevice behaiviors and custome sevice host factory: if you want to have "IoC container free" bootstrapper - it is absurd, if you need to have "IoC container free" service contract implementation - just create second "IoC container free" service contract implementation.

受限制的 HTML

  • 允许的HTML标签:<a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • 自动断行和分段。
  • 网页和电子邮件地址自动转换为链接。

相关推荐
  • 浅谈IOC--说清楚IOC是什么
    1.IOC的理论背景 2.什么是IOC 3.IOC也叫依赖注入(DI) 4.IOC的优缺点 5.IOC容器的技术剖析 6.IOC容器的一些产品 1.IOC的理论背景 我们知道在面向对象设计的软件系统中,它的底层都是由N个对象构成的,各个对象之间通过相互合作,最终实现系统地业务逻辑[1]。 图1 软件系统中耦合的对象 如果我们打开机械式手表的后盖,就会看到与上面类似的情形,各个齿轮分别带动时针、分针和秒针顺时针旋转,从而在表盘上产生正确的时间。图1中描述的就是这样的一个齿轮组,它拥有多个独立的齿轮,这些齿轮相互啮合在一起,协同工作,共同完成某项任务。我们可以看到,在这样的齿轮组中,如果有一个齿轮出了问题,就可能会影响到整个齿轮组的正常运转。 齿轮组中齿轮之间的啮合关系,与软件系统中对象之间的耦合关系非常相似。对象之间的耦合关系是无法避免的,也是必要的,这是协同工作的基础。现在,伴随着工业级应用的规模越来越庞大,对象之间的依赖关系也越来越复杂,经常会出现对象之间的多重依赖性关系,因此,架构师和设计师对于系统的分析和设计,将面临更大的挑战。对象之间耦合度过高的系统,必然会出现牵一发而动全身的情形。 图2 对象之间的依赖关系 耦合关系不仅会出现在对象与对象之间,也会出现在软件系统的各模块之间,以及软件系统和硬件系统之间。如何降低系统之间、模块之间和对象之间的耦合º
  • 我们是否有效地使用了 IoC?(Are we using IoC effectively?)
    问题 所以我的公司使用 Castle Windsor IoC 容器,但在某种程度上感觉“关闭”: 所有数据类型都在代码中注册,而不是在配置文件中。 所有数据类型都经过硬编码以使用一种接口实现。 事实上,对于几乎所有给定的接口,只有一种实现。 所有已注册的数据类型都有一个默认构造函数,因此 Windsor 不会为任何已注册的类型实例化对象图。 设计系统的人坚持 IoC 容器使系统更好。 我们有超过1200个公开课,所以它是一个大的系统,在那里你希望找到像温莎框架的那种。 但我仍然持怀疑态度。 我的公司是否有效地使用了 IoC? 与使用new关键字新建对象相比,使用 Windsor 新建对象是否有优势? 回答1 简短的回答:不,您的公司没有有效地使用 DI。 稍微长一点的答案:主要问题是所有类都有默认构造函数。 在这种情况下,您如何解决依赖关系? 您的构造函数要么具有像这样的硬编码依赖项: public Foo() { IBar bar = new Bar(); } 在这种情况下,您不能在不重新编译该应用程序的情况下更改依赖项。 更糟糕的是,他们可能会使用静态服务定位器反模式: public Foo() { IBar bar = Container.Resolve<IBar>(); } DI 容器应该解析应用程序的组合根中的整个依赖关系图并让开。 通常
  • 为什么 IoC / DI 在 Python 中不常见?(Why is IoC / DI not common in Python?)
    问题 在 Java 中 IoC/DI 是一种非常普遍的做法,它广泛用于 Web 应用程序、几乎所有可用的框架和 Java EE。 另一方面,也有很多大型 Python Web 应用程序,但除了 Zope(我听说它的编码应该非常糟糕)IoC 在 Python 世界中似乎并不常见。 (如果你认为我错了,请列举一些例子)。 当然,有几个流行的 Java IoC 框架的克隆可用于 Python,例如 springpython。 但它们似乎都没有得到实际使用。 至少,我从来没有遇到过基于 Django 或 sqlalchemy+ <insert your favorite wsgi toolkit here>的 Web 应用程序,它使用类似的东西。 在我看来,IoC 具有合理的优势,例如可以轻松替换 django-default-user-model,但是在 Python 中大量使用接口类和 IoC 看起来有点奇怪,而不是»pythonic«。 但也许有人有更好的解释,为什么 IoC 没有在 Python 中广泛使用。 回答1 我实际上并不认为 DI/IoC 在 Python 中那么罕见。 什么是不常见的,但是,是DI / IoC框架/容器。 想一想:DI 容器有什么作用? 它允许你 将独立的组件连接到一个完整的应用程序中...... ...在运行时。 我们有“连接在一起”和“运行时”的名称
  • spring面试题:spring控制反转(IOC)
    spring控制反转(IOC) 此文的大部分内容都来自于这篇博客:https://www.cnblogs.com/superjt/p/4311577.html 个人认为这篇博客讲的的确挺通俗易懂的 1. 为什么要有IOC 背景: 我们都知道,在采用面向对象方法设计的软件系统中,它的底层实现都是由N个对象组成的,所有的对象通过彼此的合作,最终实现系统的业务逻辑。 图1. 软件系统中耦合的对象 问题出现:系统对象的耦合度过高 图2. 对象之间复杂的依赖关系 如果我们打开机械式手表的后盖,就会看到与上面类似的情形,各个齿轮分别带动时针、分针和秒针顺时针旋转,从而在表盘上产生正确的时间。图1中描述的就是这样的一个齿轮组,它拥有多个独立的齿轮,这些齿轮相互啮合在一起,协同工作,共同完成某项任务。我们可以看到,在这样的齿轮组中,如果有一个齿轮出了问题,就可能会影响到整个齿轮组的正常运转。齿轮组中齿轮之间的啮合关系,与软件系统中对象之间的耦合关系非常相似。对象之间的耦合关系是无法避免的,也是必要的,这是协同工作的基础。现在,伴随着工业级应用的规模越来越庞大,对象之间的依赖关系也越来越复杂,经常会出现对象之间的多重依赖性关系,因此,架构师和设计师对于系统的分析和设计,将面临更大的挑战。对象之间耦合度过高的系统,必然会出现牵一发而动全身的情形。 IOC被提出: 耦合关系不仅会出现在对象与对象之间
  • 为什么我需要一个IoC容器而不是简单的DI代码? [关闭](Why do I need an IoC container as opposed to straightforward DI code? [closed])
    问题 关门了。 这个问题是基于意见的。 它当前不接受答案。 6年前关闭。 已锁定。 该问题及其答案被锁定,因为该问题是题外话,但具有历史意义。 它目前不接受新的答案或互动。 我使用依赖注入(DI)已有一段时间了,注入了构造函数,属性或方法。 我从来没有觉得需要使用控制反转(IoC)容器。 但是,我阅读的内容越多,社区使用IoC容器的压力就越大。 我玩过.NET容器,如StructureMap,NInject,Unity和Funq。 我仍然看不到IoC容器如何使我的代码受益/改进。 我也害怕在工作中开始使用容器,因为我的许多同事会看到他们不理解的代码。 他们中的许多人可能不愿意学习新技术。 请说服我,我需要使用IoC容器。 与工作中的开发人员交谈时,我将使用这些参数。 回答1 哇,简直无法相信乔尔会喜欢这个: var svc = new ShippingService(new ProductLocator(), new PricingService(), new InventoryService(), new TrackingRepository(new ConfigProvider()), new Logger(new EmailLogger(new ConfigProvider()))); 在此: var svc = IoC.Resolve<IShippingService>()
  • 理解透彻!Spring中BeanFactory与FactoryBean分析
    前言 理解FactoryBean是非常非常有必要的,因为在Spring中FactoryBean最为典型的一个应用就是用来创建AOP的代理对象,不仅如此,而且对理解Mybatis核心源码也非常有帮助!如果甘愿crud,做个快乐的码农,那我就哦豁豁豁豁豁豁豁豁豁豁豁豁豁豁...... BeanFactory和FactoryBean同样都是spring的接口,名字看起来很相似,但是我觉得要混淆还是很困难的!尽管Spring揭秘一书的作者都喜欢写上这一句。 请不要混淆BeanFactory 和 FactoryBean。 1、BeanFactory BeanFactory,以Factory结尾,表示它是一个工厂(接口), 它负责生产和管理bean的一个工厂。在Spring中,BeanFactory是工厂的顶层接口,也是IOC容器的核心接口,因此BeanFactory中定义了管理Bean的通用方法,如 getBean 和 containsBean 等,它的职责包括:实例化、定位、配置应用程序中的对象及建立这些对象间的依赖。BeanFactory只是个接口,并不是IOC容器的具体实现,所以Spring容器给出了很多种实现,如 DefaultListableBeanFactory、XmlBeanFactory、ApplicationContext等,其中XmlBeanFactory就是常用的一个
  • 编写您自己的 IOC 容器(Code your own IOC Container)
    问题 有没有人用 C# 编写自己的 IOC 容器? 还是绝大多数人使用各种框架,例如Spring。 每个的优点和缺点是什么? 回答1 自己编写是一个很好的练习,但最终您可能想要使用现有的容器。 你可以用 15 行代码从这个开始。 回答2 我喜欢这个来自 Ken Egozi 的 33 行容器实现,其灵感来自 Ayende 的 15 liner 回答3 有人用 C# 写了一个:http://ninject.org/。 它是开源的,所以你可以得到代码,看看这个人是怎么做的。 回答4 除非有很好的理由,否则我不会自己重新发明轮子并实现 IoC 容器,特别是因为有很多不错的选择,例如 Unity、Ninject 或 Spring.net。 如果您需要/想要删除对任何这些 IoC 容器的依赖,您可以尝试使用 Common Service Locator 接口。 回答5 我已经用 C# 编写了一个 IoC/DI 容器,它实现了公共服务定位器。 我写它主要是为了学习目的,但当我完成它时,我决定将它开源。 如果你们中有人想尝试 IInject,可以在这里下载。 回答6 如果您正在寻找轻量级和高性能的 IoC 容器,那么您应该查看 Munq 回答7 James Kovacs 在这里展示了一个关于这个主题的 dnrTV 剧集。 这里还写了一篇文章。 但是在文章中,他提到您可能希望使用其中一种预构建的。
  • IoC 框架在 MVC 应用程序中有什么用? [关闭](What is the use of an IoC framework in an MVC application? [closed])
    问题 就目前而言,这个问题不适合我们的问答形式。 我们希望答案得到事实、参考或专业知识的支持,但这个问题可能会引起辩论、争论、投票或扩展讨论。 如果您认为此问题可以改进并可能重新打开,请访问帮助中心以获取指导。 8 年前关闭。 我试图了解像 StructureMap 这样的 IoC 框架的使用,但我不禁认为这些“设计模式”只是无稽之谈,使代码变得更加复杂。 让我从一个我认为 IoC 有点有用的例子开始。 我认为 IoC 在处理 MVC 框架中控制器类的实例化时很有用。 在这种情况下,我正在考虑 .NET MVC 框架。 通常控制器类的实例化由框架处理。 所以这意味着您不能真正将任何参数传递给控制器​​类的构造函数。 这就是 IoC 框架可以派上用场的地方。 在 IoC 容器中的某个地方,您可以指定在调用控制器类时应实例化并传递给控制器constructor的类。 当您想对控制器进行单元测试时,这也很方便,因为您可以模拟传递给它的对象。 但是就像我说的,我可以理解为什么人们想要将它用于他们的控制器类。 但不是除此之外。 从那里开始,您可以简单地进行常规依赖注入。 但为什么不简单地这样做: public class SomeController { public SomeController() : this( new SomeObj() ) { } publiv
  • 为什么有这么多术语说同样的事情? IoC 和 DIP(Why so many terms to say the same thing? IoC and DIP)
    问题 IoC = 控制反转 DIP = 依赖倒置原则(SOLID 中的 D) 国际奥委会== DIP ? 我想是的,是真的。 构建软件的世界已经很乱了,为什么要说这么多话呢? (我知道DI (依赖注入),它与DIP和IoC不同) 更新: 根据答案,那么我们可以说:( DI )+( IoC )=(依赖倒置原则)? 回答1 我不认为你会得到一个权威的答案,因为“IoC”这个词有点过载,说“IoC的一个真正含义是......”有点学究气。 但无论如何我都会分享我的意见:) 依赖倒置是关于依赖于抽象。 考虑依赖于IStringWriter的HelloWorld类和实现类ConsoleStringWriter 。 控制反转是指框架/基础设施调用应用程序代码,而不是相反。 例如,当用户关闭 WPF 应用程序时,您不会调用框架,它会引发一个您可以订阅的事件。 它们经常组合在一起。 例如,Hibernate 依赖其 Interceptor 接口定义的抽象来实现 IoC。 从拦截器的角度来看,控制是颠倒的——Hibernate 调用拦截器。 另一个例子是IHandle<T> ,其中 T 是一个事件、命令或消息——基础设施在正确的时间调用处理程序。 它令人困惑,因为我们称它们为“IoC 容器”,但是您可以在不进行 IoC 的情况下进行 DI。
  • 抛开Spring去理解IOC思想 - 原来IOC容器这么简单
    很多小伙伴习惯把 IOC 思想或者 IOC 容器把 Spring 接合在一起,这其实对于学习 IOC 来说是添加难度的,Spring 中复杂的代码逻辑以及丰富的功能给 IOC 学习者带来一定的困扰。 在本场 Chat 中,会讲到如下内容: 在没有 IOC 思想是进行获取对象的。在 IOC 思想下如何获取对象的。IOC 和 DI 的区别是什么?通过实现一个自定义的 IOC 容器来加深我们对IOC容器的理解。 适合人群: 对 IOC 理解还不是很到位的小伙伴。 很多小伙伴们看到标题可能就会想到抛开 Spring 就不会存在 IOC 思想了,其实不然在接下来的文章中就会讲述到。很多小伙伴在理解 IOC 的时候通常会和 Spring 放到一起去学习,首先呢 Spring 设计的非常之巧妙而且里面包含了很多除去 IOC 的其他功能。这样会导致我们在 Spring 的基础去理解 IOC 就变得很困难。很难抓住其核心思想。所以本文的标题的含义就是单纯的去理解 IOC 思想,然后通过自定义的 IOC 去加深对 IOC 的理解。看完本文之后再去理解 Spring 中的 IOC 其实思想是一致的,只是实现上有些出入。毕竟 Spring 是大神们经过深思熟虑后的成果。 传统的思想(没有 IOC 容器的情况下) 在没有 IOC 容器的情况下,如果我们需要某个类具体的操作如下所示: 传统的 Bean 创建
  • Spring的IOC和AOP原理
    目录 Spring的IOC和AOP原理 IoC(Inversion of Control) AOP(Aspect Oriented Programming) spring 的优点? Spring的IOC和AOP原理 本文讲的是面试之Spring框架IOC和AOP的实现原理, IoC(Inversion of Control) (1). IoC(Inversion of Control)是指容器控制程序对象之间的关系,而不是传统实现中,由程序代码直接操控。控制权由应用代码中转到了外部容器,控制权的转移是所。 IoC(Inversion of Control) (1). IoC(Inversion of Control)是指容器控制程序对象之间的关系,而不是传统实现中,由程序代码直接操控。控制权由应用代码中转到了外部容器,控制权的转移是所谓反转。 对于Spring而言,就是由Spring来控制对象的生命周期和对象之间的关系;IoC还有另外一个名字——“依赖注入(Dependency Injection)”。从名字上理解,所谓依赖注入,即组件之间的依赖关系由容器在运行期决定,即由容器动态地将某种依赖关系注入到组件之中。 (2). 在Spring的工作方式中,所有的类都会在spring容器中登记,告诉spring这是个什么东西,你需要什么东西,然后spring会在系统运行到适当的时候
  • 我应该封装我的 IoC 容器吗?(Should I encapsulate my IoC container?)
    问题 想改进这篇文章吗? 提供此问题的详细答案,包括引文和解释为什么您的答案是正确的。 没有足够详细信息的答案可能会被编辑或删除。 我正在尝试决定通过额外的努力来封装我的 IoC 容器是否有意义。 经验告诉我,我应该在我的应用程序和任何第三方组件之间放置一层封装。 我只是不知道这是否接近于矫枉过正。 我可以想到我可能想要切换容器的情况。 例如,我当前的容器停止维护,或者其他容器被证明重量更轻/性能更佳并且更适合我的需求。 如果发生这种情况,那么我可能有很多重新布线工作要做。 明确地说,我正在考虑封装类型的注册和解析。 我认为封装分辨率是一件轻而易举的事情 - 我希望将 helper/util 类委托给容器是一种常见的做法。 编辑: 假设是我更喜欢以编程方式连接我的类型以实现类型安全、编译时检查和可重构性。 正是这段代码及其对容器的依赖,我正在寻求保护自己。 我也一直在将 IoC 容器用于其他几个共享许多相同关系的项目,但是使用该容器很痛苦,所以我想要改变。 但是,更改意味着我失去了注册码的可重用性。 因此,为什么我要考虑封装。 这不是一个巨大的负担,但我想减轻它。 我期待: 最小化容器/容器版本变化的影响在可能使用不同容器的项目之间提供某种程度的类型注册一致性提供对我有意义的接口方法(RegisterSingleton<T,T> 而不是 RegisterType<T,T>(
  • Spring的IOC和AOP原理
    Spring的IOC和AOP原理 本文讲的是面试之Spring框架IOC和AOP的实现原理, IoC(Inversion of Control) (1). IoC(Inversion of Control)是指容器控制程序对象之间的关系,而不是传统实现中,由程序代码直接操控。控制权由应用代码中转到了外部容器,控制权的转移是所。 IoC(Inversion of Control) (1). IoC(Inversion of Control)是指容器控制程序对象之间的关系,而不是传统实现中,由程序代码直接操控。控制权由应用代码中转到了外部容器,控制权的转移是所谓反转。 对于Spring而言,就是由Spring来控制对象的生命周期和对象之间的关系;IoC还有另外一个名字——“依赖注入(Dependency Injection)”。从名字上理解,所谓依赖注入,即组件之间的依赖关系由容器在运行期决定,即由容器动态地将某种依赖关系注入到组件之中。 (2). 在Spring的工作方式中,所有的类都会在spring容器中登记,告诉spring这是个什么东西,你需要什么东西,然后spring会在系统运行到适当的时候,把你要的东西主动给你,同时也把你交给其他需要你的东西。所有的类的创建、销毁都由 spring来控制,也就是说控制对象生存周期的不再是引用它的对象,而是spring。对于某个具体的对象而¨
  • 对IOC的相关理解总结
    目录 当前没有去添加对应的源码,只是自己的一些总结,可能理解有错误或不到位,还请指出。 一、对IOC和DI的基本认识 (一)理解IoC,即“控制反转” (二)IoC具体做什么? (三)理解IoC和DI的关系 二、对IOC容器初始化的理解 三、对DI依赖注入的理解 参考书籍、文献和资料 当前没有去添加对应的源码,只是自己的一些总结,可能理解有错误或不到位,还请指出。 一、对IOC和DI的基本认识 (一)理解IoC,即“控制反转” 在Java开发中,Ioc意味着将你设计好的对象交给容器控制,而不是传统的在你的对象内部直接控制。理解好Ioc的关键是要明确“谁控制谁,控制什么,为何是反转(有反转就应该有正转了),哪些方面反转了”,那我们来深入分析一下: ●谁控制谁,控制什么:传统Java SE程序设计,我们直接在对象内部通过new进行创建对象,是程序主动去创建依赖对象;而IoC是有专门一个容器来创建这些对象,即由Ioc容器来控制对象的创建以及外部资源获取(不只是对象包括比如文件等)。 ●为何是反转,哪些方面反转了:有反转就有正转,传统应用程序是由我们自己在对象中主动控制去直接获取依赖对象,也就是正转;而反转则是由容器来帮忙创建及注入依赖对象:由容器帮我们查找及注入依赖对象,对象只是被动的接受依赖对象,所以是反转,依赖对象的获取被反转了。 (二)IoC具体做什么? IoC不是一种技术
  • 2021-04-21 笔记
    Spring IOC与Di 1.1、IoC是什么   Ioc—Inversion of Control,即“控制反转”,不是什么技术,而是一种设计思想。在Java开发中,Ioc意味着将你设计好的对象交给容器控制,而不是传统的在你的对象内部直接控制。如何理解好Ioc呢?理解好Ioc的关键是要明确“谁控制谁,控制什么,为何是反转(有反转就应该有正转了),哪些方面反转了”,那我们来深入分析一下:   ●谁控制谁,控制什么:传统Java SE程序设计,我们直接在对象内部通过new进行创建对象,是程序主动去创建依赖对象;而IoC是有专门一个容器来创建这些对象,即由Ioc容器来控制对 象的创建;谁控制谁?当然是IoC 容器控制了对象;控制什么?那就是主要控制了外部资源获取(不只是对象包括比如文件等)。   ●为何是反转,哪些方面反转了:有反转就有正转,传统应用程序是由我们自己在对象中主动控制去直接获取依赖对象,也就是正转;而反转则是由容器来帮忙创建及注入依赖对象;为何是反转?因为由容器帮我们查找及注入依赖对象,对象只是被动的接受依赖对象,所以是反转;哪些方面反转了?依赖对象的获取被反转了。 1.2、IoC能做什么   IoC 不是一种技术,只是一种思想,一个重要的面向对象编程的法则,它能指导我们如何设计出松耦合、更优良的程序。传统应用程序都是由我们在类内部主动创建依赖对象
  • 为什么动态语言不需要IOC容器(Why are IOC containers unnecessary with dynamic languages)
    问题 http://herdingcode.com/herding-code-68-new-year-shenanigans/上的《成群代码》 68号播客中的某人说,IOC容器在Python或Javascript或类似的词上没有位置。 我假设这是常规知识,并且适用于所有动态语言。 为什么? 动态语言又使IOC容器不必要吗? 回答1 当对象在另一个类上调用“ new”时,IoC提供了一种打破耦合的机制。 这种耦合将调用对象与它实现的任何接口的实例化实现联系在一起。 在当你的名字引用类的静态语言(调用new就可以了),没有歧义。 这与特定类别紧密相关。 在动态语言中,调用new X是“在执行时实例化定义为X任何类”的占位符。 这是一个较宽松的耦合,因为它仅与名称X耦合。 这种细微的差别意味着,在动态语言中,您通常可以更改X是什么,因此,关于实例化哪个类的决定仍然可以在调用类之外进行修改。 但是,我个人发现IoC有两个优点,我不能依靠动态语言来允许注入。 通过构造函数传递依赖关系的副作用之一是,您最终会获得非常松散,可重用且易于测试的“构建块”类。 他们不知道打算在什么上下文中使用它们,因此您可以在各处重复使用它们。 另一个结果是使用显式代码进行接线。 正确完成后,就可以清楚地代表您的应用程序的结构,并将其分解为子系统和生命周期。 这使人们可以明确地决定与类关联的生命周期或子系统
  • IoC 和 DI 之间的区别究竟在哪里 [重复](Where exactly is the difference between IoC and DI [duplicate])
    问题 这个问题在这里已经有了答案: 10 年前关闭。 可能的重复: 控制反转 < 依赖注入 我总是在同一上下文中阅读 IoC(控制反转)和 DI(依赖注入)。 IoC 和 DI 之间到底有什么区别? IoC 与 DI 有何不同? 回答1 在通常的用法中,这些术语已成为某种同义词。 IoC 的最初想法——控制反转——与“好莱坞原则:”不要打电话给我们,我们会打电话给你。 在传统应用中,开发人员会编写业务代码和框架代码。 然后业务代码将调用框架代码来完成任务。 在 IoC 模型下,您“反转”该模型并创建一个框架,该框架接受业务模块并调用它们来完成任务。 这一原则体现在几个开发框架中,包括旧的智能客户端软件工厂和新的Prism(或 WPF/Silverlight 的复合应用程序) 。 在这些模型中,UI 模块注册到 IoC 容器并根据配置和用户操作根据需要加载。 虽然功能强大,但这些模型也往往具有非常陡峭的学习曲线。 依赖注入是一种通过允许依赖对象被外部调用者注入到类/方法中来从实现中移除内部依赖的技术(实际上很难称之为模式)。 IoC 框架使用依赖注入向框架例程提供用户模块和其他相关代码,将它们“粘合在一起”。 IoC 框架大量使用依赖注入,因为这是允许它们“呼叫你”的机制。 IoC 容器,例如 Castle Windsor 和 Structure Map
  • SpringIoc理解
    SpringIoc理解 分享Iteye的开涛对Ioc的精彩讲解1.1、IoC是什么1.2、IoC能做什么1.3、IoC和DI 二、分享Bromon的blog上对IoC与DI浅显易懂的讲解2.1、IoC(控制反转)2.2、DI(依赖注入) 三、我对IoC(控制反转)和DI(依赖注入)的理解四、小结 学习过Spring框架的人一定都会听过Spring的IoC(控制反转) 、DI(依赖注入)这两个概念,对于初学Spring的人来说,总觉得IoC 、DI这两个概念是模糊不清的,是很难理解的,今天和大家分享网上的一些技术大牛们对Spring框架的IOC的理解以及谈谈我对Spring Ioc的理解。 分享Iteye的开涛对Ioc的精彩讲解 首先要分享的是Iteye的开涛这位技术牛人对Spring框架的IOC的理解,写得非常通俗易懂,以下内容全部来自原文,原文地址:https://www.cnblogs.com/xdp-gacl/p/4249939.html 1.1、IoC是什么 Ioc—Inversion of Control,即“控制反转”,不是什么技术,而是一种设计思想。在Java开发中,Ioc意味着将你设计好的对象交给容器控制,而不是传统的在你的对象内部直接控制。如何理解好Ioc呢?理解好Ioc的关键是要明确“谁控制谁,控制什么,为何是反转(有反转就应该有正转了),哪些方面反转了”
  • IOC和DI(控制反转和依赖注入)
    IOC和DI(控制反转和依赖注入) 学习过Spring框架的人一定都会听过Spring的IoC(控制反转) 、DI(依赖注入)这两个概念,对于初学Spring的人来说,总觉得IoC 、DI这两个概念是模糊不清的,是很难理解的,今天和大家分享网上的一些技术大牛们对Spring框架的IOC的理解以及谈谈我对Spring Ioc的理解。 一、分享Iteye的开涛对IoC的精彩讲解   首先要分享的是Iteye的开涛这位技术牛人对Spring框架的IOC的理解,写得非常通俗易懂,以下内容全部来自原文,原文地址: http://jinnianshilongnian.iteye.com/blog/1413846 1.1 什么是IoC   Ioc—Inversion of Control,即“控制反转”,不是什么技术,而是一种设计思想。在Java开发中,Ioc意味着将你设计好的对象交给容器控制,而不是传统的在你的对象内部直接控制。如何理解好Ioc呢?理解好Ioc的关键是要明确“谁控制谁,控制什么,为何是反转(有反转就应该有正转了),哪些方面反转了”,那我们来深入分析一下:   ●谁控制谁,控制什么:传统Java SE程序设计,我们直接在对象内部通过new进行创建对象,是程序主动去创建依赖对象;而IoC是有专门一个容器来创建这些对象,即由Ioc容器来控制对象的创建;谁控制谁
  • Spring IOC的实现原理理解
    由于对象之间存在了复杂的依赖关系,导致耦合度较高,为了解决这个问题,所以提出了ioc原理ioc(控制反转)是什么 其实简单来说就是你在创建对象的时候不用自己去new 一个对象,而是有别的给你提供,在spring 中就有ioc容器给你提供对象。ioc在spring中怎么实现 我个人觉得spring中的ioc实现其实就是加强版的工厂模式,然后它通过加载配置文件来初始化对象。在这里配置文件可以用xml , properties等都可以,但是不同的配置文件类型需要用不同的解析器去解读。 然后 Spring Bean的创建的使用工厂模式,这里有一系列的Bean工厂。BeanFactory作为最顶层的一个接口类,它定义了IOC容器的基本功能规范。 public interface BeanFactory { //对FactoryBean的转义定义,因为如果使用bean的名字检索FactoryBean得到的对象是工厂生成的对象, //如果需要得到工厂本身,需要转义 String FACTORY_BEAN_PREFIX = "&"; //根据bean的名字,获取在IOC容器中得到bean实例 Object getBean(String name) throws BeansException; //根据bean的名字和Class类型来得到bean实例,增加了类型安全验证机制。 Object