IOC

Today when I preview the Guice's UserGuide, my focus is attracted by IOC 'again'.

About IOC, I did not attain a clear picture of it for a long time for I usually the "decouping" is the 'consumer classes' and 'interface' rather than 'service provide classes'. Maybe It's the result of the short of the real-mass development. From the CSDN, and the example from Guice, I thought I got the key point as mentioned above.

It seems that The Facotory pattern always come into our mind when we talk about the IOC. From the low level perspective, It provide the decoupling between 'consumer classes' and 'service provide classes' . however, It's short of flexible for it's always a singleton class, and maybe the trade-off of the cost will become more marked.

The Best solution is the IOC, which only provide the 'interface class' as the functional parameters and use the 'interface class' in the functional, provided the concrete impl, maybe until runtime, by the 'system class'.

Notes:
Don't Call me, I'll Call you. = Don't Call the Concrete Implementation Class, The System Class will invoke the right correct implementation class to your functions whose parameters would be the interface.

Couple which and which = Couple 'consumer' and 'service provider'

A vividly example is as follows:
//Common
public class Girl {
void kiss(){
//Couple the 'consumer class' and the 'service provide class'
Boy boy = new Boy();
}
}

//Factory Pattern
public class Girl {
void kiss(){
//Decouple!
BoyInterface boy = BoyFactory.createBoy();
}
}

//IOC
public class Girl {
// IOC
void kiss(BoyInterface boy){
boy.kiss();
}
}