还是没有明白IoC的好处

1)Bo 不知道Ainstance 是否为null?他不知道他的成员变量是否是被初始化了(顺便有个问题,java为什么要构造函数?)<构造还属初始化比较好>
2) 作为一个变量,他在class里面作用域扩大的结果就是组件A的状态不能有mehod的自己控制,而是由整个class的所有方法都有可能修改A的状态!危险!(全局变量的恶梦的开始)(至少在方法里面的时候,没有同步的问题了!)

当然不可否认ioc有它的优势所在,但是为了适应它,也要付出代价,这就是一个平衡的问题了

例子

BO{
   StringBuffer b;//setter getter

   do1{ b.append("do1");; pirnt(b);}

  do2{b.append("do2");;print(b);}
}

作为client调用的时候是不是要非常小心？

BO{
   

   do1{StringBuffer b ##;  b.append("do1");; pirnt(b);}

  do2{ StringBuffer b ##; b.append("do2");;print(b);}
}

client的任务轻松了一些

frankensteinlin

就你上面的例子,是不足以说明问题的。
类试上面的代码，都是设计上的问题。
而不是Ioc带来的潜在的危险或是优势...

给出尼的设计?

你要喜欢构造函数初始化，就从构造函数注射A给BO好了，有什么区别？BO怎么会不知道A是否为null？setter里面和ctor里面都可以检查的呀。



业务对象都是没有状态的，哪来的修改状态一说？又哪里需要什么同步？不要叫什么“危险”啦“噩梦”啦，这里都是程序员，都能看懂代码。请举个例子出来展现这种危险性的存在。

如果你们的bo所依赖的对象都是无状态的,我就没话说了

IOC的方式对于写测试代码明显的有好处。这一点已经足够了。
另外“什么client要传入组件”，你说的client是使用者，你不会不懂封装下，再给调用者使用啊。
另外，假设A要使用一个StringUtil。我也不会傻到要IOC进去.

这跟讨论IOC有什么关系,有状态的对象还是对象，想对它怎么IOC就怎么IOC.

bo  mailcompent 暴露给客户，无疑是破坏了封装，客户对组件的借口明显多了一个，这是不争的事实！为什么checkUser一定要mailCompent? 为什么不是 直接fax，或者什么也不作，只是写log？。。。客户为什么要知道bo的具体实现?对于checkUser来说本来是封闭的，现在变成开放的了！

使用接口隔离啊,用户永远都不知道有这个方法，除非他够狠，向下cast