首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

为什么我得到“这个构造函数与角度依赖注入不兼容”

这个问题涉及到构造函数和角度依赖注入的兼容性问题。构造函数是一种用于创建对象的特殊函数,而角度依赖注入是一种设计模式,用于将依赖项注入到对象中。

当出现“这个构造函数与角度依赖注入不兼容”的错误时,可能是因为构造函数的参数类型与角度依赖注入的期望类型不匹配。角度依赖注入通常会根据参数类型来确定要注入的依赖项,如果参数类型不匹配,就会导致兼容性问题。

解决这个问题的方法有几种:

  1. 检查构造函数的参数类型:确保构造函数的参数类型与角度依赖注入的期望类型一致。如果不一致,可以尝试修改构造函数的参数类型,或者修改角度依赖注入的配置,使其与构造函数的参数类型匹配。
  2. 使用类型转换:如果构造函数的参数类型与角度依赖注入的期望类型相似但不完全匹配,可以尝试使用类型转换来解决兼容性问题。例如,可以将参数类型转换为期望类型,然后再进行注入。
  3. 检查依赖项的可用性:确保要注入的依赖项在角度依赖注入时是可用的。如果依赖项未正确初始化或不可访问,也会导致兼容性问题。

总结起来,当出现“这个构造函数与角度依赖注入不兼容”的错误时,需要检查构造函数的参数类型、角度依赖注入的配置以及依赖项的可用性。根据具体情况进行调整和修复,以确保兼容性。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

依赖注入依赖注入模式

机器猫的那个四次元口袋就是一个理想的依赖注入容器,大熊只需要告诉哆啦A梦相应的需求,它就能从这个口袋中得到相应的法宝。...依赖注入容器亦是如此,服务消费者只需要告诉容器所需服务的类型(一般是一个服务接口或者抽象服务类),就能得到之匹配的服务实例。...我们可以通过三种主要的方式达到这个目的,这就是接下来着重介绍的三种依赖注入方式。 构造注入 构造注入就是在构造函数中借助参数将依赖的对象注入到由它创建的对象之中。...依赖注入容器在调用构造函数创建一个Foo对象之后,它会自动调用这个Initialize方法对只读属性Bar进行赋值。...对于前面介绍的这几种注入方式,构造注入是最为理想的形式,个人建议使用属性注入和方法注入(前面介绍的这种基于约定的方法注入除外)。

1.5K30

简述你对ioc的理解_对剩余价值的理解总结

理解DI的关键是:“谁依赖谁,为什么需要依赖,谁注入谁,注入了什么”,那我们来深入分析一下: ●谁依赖于谁:当然是应用程序依赖于IoC容器; ●为什么需要依赖:应用程序需要IoC容器来提供对象需要的外部资源...比如说A依赖于B,B依赖于A 通过dependsOn注解去指定。此时执行到这里就会抛出异常。这里所指并非是构造函数的循环依赖。...如果说在createBeanInstance这个方法中在创建Bean的时候它会去检测你的依赖关系,会去检测你的构造器。...这就是为什么Spring IOC不能解决构造器循环依赖的原因。因为你还没来的急放入缓存你的对象是不存在的。所以不能创建。同理@Bean标注的循环依赖方法也是不能解决的,跟这个同理。...至此,构造器循环依赖和@Bean的循环依赖还有多例Bean的循环依赖为什么不能解决已经解释清楚。然后如果说,Bean创建成功了。那么会走后面的逻辑。

47620

依赖注入: 依赖注入模式

之所以将其命名为Cat,源于我们大家都非常熟悉的一个卡通形象“机器猫(哆啦A梦)”。机器猫的那个四次元口袋就是一个理想的DI容器,大熊只需要告诉哆啦A梦相应的需求,它就能从这个口袋中得到相应的法宝。...DI容器亦是如此,服务消费者只需要告诉容器所需服务的类型(一般是一个服务接口或者抽象服务类),就能得到之匹配的服务实例。...二、构造注入 构造注入就在在构造函数中借助参数将依赖的对象注入到创建的对象之中。...对于上面介绍的这几种注入方式,构造注入是最为理想的形式,个人建议使用属性注入和方法注入(上面介绍这种基于约定的方法注入除外)。...反对使用Service Locator上面提到的反对使用属性注入和方法注入具有类似的缘由。

1.6K40

为什么IDEA推荐你使用@Autowired?

但是当我们使用IDEA写代码的时候,经常会发现@Autowired注解下面是有小黄线的,我们把小鼠标悬停在上面,可以看到这个如下图所示的警告信息: 那么为什么IDEA会给出Field injection...三种依赖注入的对比 在知道了Spring提供的三种依赖注入方式之后,我们继续回到本文开头说到的问题:IDEA为什么推荐使用Field Injection呢?...:可靠 Setter Injection:不可靠 由于构造函数有严格的构建顺序和不可变性,一旦构建就可用,且不会被更改。...可维护性 主要从更容易阅读、分析依赖关系的角度来评判: Field Injection:差 Constructor Injection:好 Setter Injection:差 还是由于依赖关键的明确,...从构造函数中可以显现的分析出依赖关系,对于我们如何去读懂关系和维护关系更友好。

57920

依赖注入

引入依赖注入(DI)。 2.使用依赖注入 这个主题比较大,无法用很短的篇幅讲完。并且后面我们会详细的探讨依赖注入,所以现在只会从使用依赖注入的类的角度来讲解一些基本的要点。...之所以说是互补的方式,是因为针对接口编码只能让代码部分解耦,还是没有解决直接调用被依赖类的构造函数的问题;而使用依赖注入虽然解决了这个问题,但是使用依赖注入依赖于针对接口编程的。...三种依赖注入方式及其优缺点 首先大家思考一下为什么在项目中会要求大家在控制器层使用属性注入,在业务逻辑层使用构造函数注入?...脱离了IOC框架,这个类仍然可以工作(穷人的依赖注入)。 一旦对象初始化成功了,这个对象的状态肯定是正确的。 缺点: 构造函数会有很多参数。...缺点: 新加入依赖时会破坏原有的方法签名,如果这个方法已经被其他很多模块用到就很麻烦。 构造方法注入一样,会有很多参数。

85530

循环依赖产生及规避

在刚开始学Spring的时候,一直想不通: 为什么Spring除了构造函数之外还要在Bean生命周期里有一个额外的初始化方法? 这个初始化方法和构造函数到底有什么区别?...为什么Spring建议将初始化的逻辑写在生命周期里的初始化方法里? 现在,把依赖调解结合起来看,解释就十分清楚了: 为了进行依赖调解,Spring在调用构造函数时是没有将依赖注入进来的。...根据上面的分析我们应该得到了以下共识: 通过构造函数传递依赖的做法是有可能造成无法自动调解的循环依赖的。...纯粹通过Field/GetterSetter进行依赖注入造成的循环依赖是完全可以被自动调解的。 因此这样得到了一个认为正确的结论。...当然,没有任何“建议使用构造注入”的意思。相反,认为能够“优雅地、不引入循环依赖地使用构造注入”是一个要求更高的、更优雅的做法。

46930

一个非典型Spring循环依赖的问题分析

在刚开始学Spring的时候,一直想不通: 为什么Spring除了构造函数之外还要在Bean生命周期里有一个额外的初始化方法? 这个初始化方法和构造函数到底有什么区别?...为什么Spring建议将初始化的逻辑写在生命周期里的初始化方法里? 现在,把依赖调解结合起来看,解释就十分清楚了: 为了进行依赖调解,Spring在调用构造函数时是没有将依赖注入进来的。...根据上面的分析我们应该得到了以下共识: 通过构造函数传递依赖的做法是有可能造成无法自动调解的循环依赖的。...纯粹通过Field/GetterSetter进行依赖注入造成的循环依赖是完全可以被自动调解的。 因此这样得到了一个认为正确的结论。...当然,没有任何“建议使用构造注入”的意思。相反,认为能够“优雅地、不引入循环依赖地使用构造注入”是一个要求更高的、更优雅的做法。

43920

一个非典型Spring循环依赖的问题分析

在刚开始学Spring的时候,一直想不通: 为什么Spring除了构造函数之外还要在Bean生命周期里有一个额外的初始化方法? 这个初始化方法和构造函数到底有什么区别?...如果不在构造函数中使用依赖注入的bean而仅仅使用构造函数中的参数,虽然没有问题,但是这就导致了这个bean强依赖于他的入参bean。当后续出现循环依赖时无法进行调解。...根据上面的分析我们应该得到了以下共识: 通过构造函数传递依赖的做法是有可能造成无法自动调解的循环依赖的。...纯粹通过Field/GetterSetter进行依赖注入造成的循环依赖是完全可以被自动调解的。 因此这样得到了一个认为正确的结论。...当然,没有任何“建议使用构造注入”的意思。相反,认为能够“优雅地、不引入循环依赖地使用构造注入”是一个要求更高的、更优雅的做法。

95620

这个Spring循环依赖的坑,90%以上的人都不知道

在刚开始学Spring的时候,一直想不通: 为什么Spring除了构造函数之外还要在Bean生命周期里有一个额外的初始化方法? 这个初始化方法和构造函数到底有什么区别?...如果不在构造函数中使用依赖注入的bean而仅仅使用构造函数中的参数,虽然没有问题,但是这就导致了这个bean强依赖于他的入参bean。当后续出现循环依赖时无法进行调解。...根据上面的分析我们应该得到了以下共识: 通过构造函数传递依赖的做法是有可能造成无法自动调解的循环依赖的。...纯粹通过Field/GetterSetter进行依赖注入造成的循环依赖是完全可以被自动调解的。 因此这样得到了一个认为正确的结论。...当然,没有任何“建议使用构造注入”的意思。相反,认为能够“优雅地、不引入循环依赖地使用构造注入”是一个要求更高的、更优雅的做法。

1.1K10

为什么IDEA推荐你使用@Autowired ?

但是当我们使用IDEA写代码的时候,经常会发现@Autowired注解下面是有小黄线的,我们把小鼠标悬停在上面,可以看到这个如下图所示的警告信息: 那为什么IDEA会给出Field injection...三种依赖注入的对比 在知道了Spring提供的三种依赖注入方式之后,我们继续回到本文开头说到的问题:IDEA为什么推荐使用Field Injection呢?...:可靠 Setter Injection:不可靠 由于构造函数有严格的构建顺序和不可变性,一旦构建就可用,且不会被更改。...可维护性 主要从更容易阅读、分析依赖关系的角度来评判: Field Injection:差 Constructor Injection:好 Setter Injection:差 还是由于依赖关键的明确,...从构造函数中可以显现的分析出依赖关系,对于我们如何去读懂关系和维护关系更友好。

67220

Android技术栈(三)依赖注入技术的探讨实现

那么问题来了,如果这是一个实际的项目,如果这些依赖的对象还有互相依赖,如果这些类的构造函数发生了改变,如果逻辑实现的子类发生了变更,会发生什么? Boom!...如传统的使用构造函数构造对象,又或者是工厂模式,Builder模式,JavaBean模式等。Liteproj必须从一开始就兼容这些现有方案,否则就是开倒车了。...>,第二行是最外层是dependency标签,这个标签必须要指定一个owner的属性来指定此依赖配置文件所兼容的类型,下面的xml中指定了android.app.Application作为此xml所兼容的类型...然后var标签中包裹的new标签表明此依赖使用构造函数创建,使用arg标签填入构造函数的参数并用ref属性引用一个上文中已经存在的另一个已经声明的var的name....DependencyManager组件的生命周期绑定,在组件生命周期结束时,会释放自己占有的所有资源. 7.隐式装配 在继续对比Dagger和Spring两者依赖注入的行为中,发现Spring有一个

77900

是否需要使用依赖注入容器?

译作 面向对象 mock 译作 模拟 anti-patterns 译作 反模式 hardcoded 译作 硬编码 ---- 正文 在上一篇 什么是依赖注入 一文中,从 Web 项目的角度出发,结合实例讲解了...想明确的是,在实现「依赖注入容器」时涉及 Symfony 相关功能,所以我将使用 Zend 框架示例来说明。 这边涉及框架之争。...为了完成这样的工作,「依赖注入容器」需要知道构造函数参数及其对应的依赖组件的对应关系。 下面以硬编码的方式实现一个 Zend_Mail 容器: <?...等等,聪明如你怎么可能没有看出这个容器还不够完美呢 -- 它包含硬编码!因此,我们需要更进一步,将所需要的数据以构造函数的参数形式添加到容器内会更好: <?...依赖组件并不知道它是由容器管理的,或许依赖组件根本就不知道「依赖注入容器」的存在。这就是为什么容器能够管理任何 PHP 对象的奥秘。

2.1K20

有经验的Java开发者和架构师容易犯的10个错误(上)

为什么Java初学者能够方便的从网上找到相对应的开发建议呢?每当我去网上搜索想要的建议的时候,总是能发现一 大堆是关于基本入门的教程、书籍以及资源。...同样也发现网上到处充斥着从宽泛的角度描述一个大型的企业级项目:如何扩展你的架构,使用消息总线,如何数据 库互联,UML图表使用以及其它高层次的信息。...10、错误地使用或者误解了依赖注入 对于一个企业级项目来说,依赖注入通常被认为是好的概念。存在一种误解——如果使用依赖注入就不会出现问题。但是这是真的吗?...当对象真正被创建时,仅仅需要在构造函数中传入预先配置好的对象(构造函数注入)或者使用方法(方法注入)。 然而总的思想是指仅仅传递对象需要的依赖关系。...从使用依赖注入角度来看,前一段代码中注入的范围很大,那就意味着有了更多的变化空 间,但是容易造成代码的功能不单一,同时增加了代码测试的复杂度。

34420

@Autowire和@Resource注解使用的正确姿势,别再用错的了!!

这段是Spring工作组的建议,大致翻译一下: 属性字段注入的方式推荐,检查到的问题是:Spring团队建议:"始终在bean中使用基于构造函数依赖注入,始终对强制性依赖项使用断言" 如图 Field...注入警告 注入方式 虽然当前有关Spring Framework(5.0.3)的文档仅定义了两种主要的注入类型,但实际上有三种: 基于构造函数依赖注入 public class UserServiceImpl...的构造函数这个过程当中就得初始化完成,这个是基于字段的依赖注入做不到的地方.只能使用基于构造函数依赖注入的方式 掩盖单一职责的设计思想 我们都知道在OOP的设计当中有一个单一职责思想,如果你采用的是基于构造函数依赖注入的方式来使用...隐藏依赖性 当你使用Spring的IOC的时候,被注入的类应当使用一些public类型(构造方法,和setter类型方法)的方法来向外界表达:需要什么依赖.但是基于字段的依赖注入的方式,基本都是private...结论 通过上面,我们可以看到,基于字段的依赖注入方式有很多缺点,我们应当避免使用基于字段的依赖注入.推荐的方法是使用基于构造函数和基于setter的依赖注入.对于必需的依赖项,建议使用基于构造函数注入

1.2K10

只因多看了一眼提示,又一次刷新了@Autowired注释的认知

翻译过来就是:字段注入推荐的,Spring团队建议:“始终在bean中使用基于构造函数依赖注入。始终对强制性依赖项使用断言”。...而上面三种注入方式所适用的场景也是有所区别的:1、构造注入适用具有强依赖和不变性的依赖;2、Setter注入适用于具有可选性和可变性的依赖注入;3、Field注入,尽量少使用,如果需要则使用@Resource...Field注入的缺点 Field注入的缺点很明显,比如不能像构造注入那样注入不可变的对象,依赖对外部不可见(构造器和Setter可见,而private的属性不可见),会导致组件IoC容器(比如Spring...既然Field注入这么多缺点,但为什么大家还是习惯使用呢?主要原因:太方便了,极大的缩减了代码。而且大多数业务并不需要用构造器强绑定,同时换IoC容器的可能性也极低。...为什么只对@Autowired警告 最主要的原因是:@Autowired是Spring提供的,是特定IoC提供的特定注解,框架形成了强绑定,一旦换用其他IoC框架,是无法支持注入的。

85820

2019年Java中高级面试题总结(7),228道系列查漏补缺!

为什么会有这个问题? 108、适配器模式是什么?什么时候使用? 109、什么是“依赖注入”和“控制反转”?为什么有人使用? 110、抽象类是什么?它与接口有什么区别?你为什么要使用过抽象类?...2、利用split()函数分割字符串,因为直接替换英文空格或者,逗号分隔就可以了,中文类似,分隔得到一个数组。...首先,这是编译器的要求,如果这么做,无法通过编译。其次,面向对象的编程,其中继承有个大原则,任何子类的对象都可以当成父类的对象使用。 107、什么情况下会违反迪米特法则?为什么会有这个问题?...控制反转(IOC)是 Spring 框架的核心思想,用自己的话说,就是你要做一件事,别自己可劲 new 了,你就说你要干啥,然后外包出去就好~依赖注入(DI) 在浅薄的想法中,就是通过接口的引用和构造方法的表达...111、构造注入和 setter 依赖注入,那种方式更好? 每种方式都有它的缺点和优点。构造注入保证所有的注入都被初始化,但是setter 注入提供更好的灵活性来设置可选依赖

1.6K00

Spring字段注入存在哪些问题,你知道吗?

英文稍微没有那么好的也没有关系,我们利用翻译工具看一下: 是的,Spring官方建议我们使用字段注入的方式,并且建议我们换一种方式。 哈哈,推荐使用构造方法注入。 那么疑问来了,这是为什么呢?...构造函数进行注入的,所以势必可以脱离 CourseController 而独立存在。...如此看来,字段注入的三大问题,就都可以通过使用构造注入的方式来解决。 但是,构造注入就没有问题了吗?显然不是! 当构造函数中存在较多依赖对象的时候,大量的构造器参数会让代码显得比较冗长。...假设一个类的构造器需要多个参数,那么我们想要使用这个类时,就需要事先准备好这些参数,并严格按照构造器指定的顺序一一进行传入。 那么,无论从代码的可读性还是可维护角度而言,这都不是很符合最佳实践。...这时候就可以引入 Setter 方法注入。 Setter 方法注入 Setter 方法注入构造注入看上去有点类似,而且它比构造函数更具可读性。

1.1K40

编码最佳实践——依赖注入原则

脱离了IOC框架,这个类仍然可以工作(穷人的依赖注入)。 一旦对象初始化成功了,这个对象的状态肯定是正确的。 缺点: 构造函数会有很多参数。...缺点: 新加入依赖时会破坏原有的方法签名,如果这个方法已经被其他很多模块用到就很麻烦。 构造方法注入一样,会有很多参数。 在这三种注入方式中,推荐使用构造函数注入。...最重要的原因是服务应该是独立自治的,即使脱离了DI框架,这个服务应该仍然可以工作。构造函数注入就符合这一要求,即使脱离了DI框架,仍然可以手动注入依赖的服务。...但是服务肯定是有依赖的,不然为什么要从服务定位器获取它们呢。 虽然我们对服务定位器反模式提出了这么多批判,但是它还是非常常见。因为有时候根本没有从构造函数注入的任何机会,唯一的选择就是服务定位器。...另外在没有从构造函数注入的机会时,可以考虑选择服务定位器反模式。选择模式的原则是:依赖注入模式优于服务定位器反模式,优于手动构造注入依赖,优于注入依赖

84820
领券