- 主题:懂一点点java的皮毛语法，做过一点点django，想了解springboot
我个人 从来 没明白 依赖注入 是在解决什么问题...
【 在 Mikov 的大作中提到: 】
: 要了解springboot, 你需要先了解spring,
: 要了解spirng, 你需要先了解Dependency Injection 依赖注入和 IOC, Inversion of Control, 控制反转,
: 要了解IOC, 你需要先了解 Proxy 和 InvocationHandler
: ...................
--
FROM 47.144.172.*
这么说来
语法上
这个
this.obj
换成 这个
globalScope.obj
也就解决问题了 ？
【 在 oldwatch 的大作中提到: 】
: 说穿了就是建立一个“保管”业务类实例的全局Context
: 然后大家只管用时引用就好
:
--
FROM 47.144.172.*
是这个著名的循环引用？
A a = new A()
B b = new B()
a.b = b
b.a = a
不就是多写两行代码吗... ？
【 在 donald2020 的大作中提到: 】
: 循环依赖呀，有循环依赖你没办法在初始化的时候自己去拿自己依赖的service
: 就总得有个工具在所有service初始化后再把各个service实例注入到各个service里去
:
--
FROM 47.144.172.*
抽象一点的说
如果说 A.B = B 算是请人帮忙的话
如果一系统里一堆这样的相互引用 相互借用 相互帮忙.... 可不是类似于现实里的三角债？
【 在 donald2020 的大作中提到: 】
: 不是两行代码的问题，比如十几个上百个service不同程序员写的
: 我作为A的作者，不想去了解B需要什么，它可能依赖EGH几个service，
: B同样也不想去了解EGH 们都依赖什么，又因为循环依赖也没法直接写到构造函数里保证不是null
: ...................
--
FROM 47.144.172.*
我个人是这么想的：
找个框架 干这些事 就把一些 琐碎 从我们的眼皮子底下 挪开了
从现实中来看 不足够关注小的事 往往是出事的征兆
林总说过 装备的时候 师级以下指战员要亲自上战场熟悉情况
我觉得他说的有道理
【 在 oldwatch 的大作中提到: 】
: 如果你能把自动注入/组装也弄出来，那确实就差不多了
: 最初，就是全局的公共业务类，这个阶段用Global(static）没啥问题
: 然后，为了更好组织代码，必然引出功能拆分/组合的需求
: ...................
--
FROM 47.144.172.*