K.L Repository

java可以实现内部类，但对于内部类的使用以前根本就不关心，
今天需要实现一个基于Spring的工厂时，才觉得可以使用内部类来实现，而产生这样的需求是由于以下的原因
1。我不希望调用者看到具体的工厂实现
2。工厂的概念定义有重复，Spring已经为我们实现了一些工厂比如:XmlBeanFactory，而我只是希望在其上包装成具体应用需要的工厂，而"脱离"Spring的素服－如果可以的话！:)
3。对外提供的GearWheelBeanFactory工厂，只提供一些静态的方法

解决
问题二、问题三
定义的重复，比如Spring已经提供了它安装好的工厂，比如XmlBeanFactory，但我希望在其上再实现应用要的工厂，更具有说服力的就是我需要实现的工厂比GearWheelBeanFactory需要实现特定的接口，并且需要"松耦合"Spring这样的框架（比如以后希望使用PicoContainer Framework）这样就需要建立应用级别的工厂抽象－Factory

问题一
问题一是产生内部类这个实现的最基础的动机，并不希望用户看到这样的Factory实现类？为什么不希望调用者看到？－主要是希望调用者面对的仅仅只是GearWheelBeanFactory的纯净的应用工厂，看到了Factory，一些聪明的调用就可以"看到"(反编译)具体的实现！！

所以采用内部类实现看来就是我要的，以下是GearWheelBeanFactory0.1 版本的实现

public class GearWheelBeanFactory
{

/**
* Static method: get bean from factory
* @param _configFile
* @param _beanName
* @return
*/
public static Object getBean(String _configFile , String _beanName)
{
Factory f = new Factory(_configFile);
return f.getBean(_beanName);
}



/*
* Inner class ; but you can't refers to it by out class
* even you didn't know whether is exist! and you can't find it too
*
*/
private static class Factory
{
/* */
private ClassPathResource config = null;

/* */
private XmlBeanFactory agent = null;

public Factory(String _configFile)
{
config = new ClassPathResource(_configFile);
agent = new XmlBeanFactory(config);
}
/**
* Get Bean by name
* @param beanName
* @return
*/
public Object getBean(String _beanName)
{
return agent.getBean(_beanName);
}
}

}


总结：
内部类的一些使用范例在网络上有很多，而且也有很多的注意事项
可是最关键的是它的适用范围，而这一切都源于你是否希望将内部类（不是匿名内部类）暴露给外界？！

内部类的实现比较BT，让人费解！！尤其是静态内部类、匿名内部类！
Faint!!看来要好好补补了