Spring AOP IOC 之外 —— 类的命名

规范命名,有助于思想的传承。

最近在阅读Spring的过程中,发现除了 AOP,IOC之外,还有许多被忽略的有助于阅读/理解源码的点,在此一一做笔记,供人参阅,希望有所帮助。如有错漏,希望能够指出以便修正,不胜感激。

Spring 的源码中,核心类的命名与功能划分具有一定的规范,了解后,在阅读Spring源码中,有些许的帮助。

幂等与非幂等/读写分离

Spring底层核心类,很多接口是按照幂等与非幂等/读写分离进行划分的:
BeanFactory:内部方法均为获取或者判断的方法,如:getBean,containsBean等;
ConfigurableBeanFactory:继承了BeanFactory后,内部定义了属性设置的入口,非幂等的,如:setParentBeanFactorysetConversionService
Environment:内部方法均为获取,或者判断的方法,如:containsPropertygetActiveProfiles
ConfigurableEnvironment:继承了Environment后,内部方法定义的是设置方法,非幂等的,如:setActiveProfilesmerge

命名习惯01
Spring 的 接口定义中,接口的命名有其规范性存在,
单纯的幂等性方法,直接按实际作用命名(主要为幂等性),
非幂等性,则在实际作用命名前(继承了幂等性类),增加 `Configurable`,
基础实现,则在非幂等性的基础上(继承了非幂等性类),对方法进行通用的基础实现

Environment:拥有获取 propertyprofile 的方法
ConfigurableEnvironment:拥有setActiveProfiles 等方法
AbstractEnvironment:对以上两个类方法进行基础实现


ApplicationContext:拥有获取 IDBeanFactory 等方法,如:getApplicationNamegetParentgetAutowireCapableBeanFactory
ConfigurableApplicationContext:拥有设置对应属性的方法,如:setEnvironmentsetParent
AbstractApplicationContext:对上述两个类方法进行基础实现


PropertyResolver:获取属性的方法,如:getPropertycontainsProperty
ConfigurablePropertyResolver:设置性的方法,如:setConversionServicesetPlaceholderPrefix
AbstractPropertyResolver:对以上两个类方法继续基础实现


PropertyAccessor:属性的判断及获取
ConfigurablePropertyAccessor:属性的设置
AbstractPropertyAccessor:基本实现


命名习惯02
针对向某个 Collection 中添加/注册某个实例,Spring 常用的命名方式是使用 Registry 作为后缀,就实际功能而言,这些类是将对应实例纳入Spring容器管理的入口!

ConverterRegistry:转换器注册器,提供了 addConverteraddConverterFactory等方法
AliasRegistry:别名注册器,registerAliasremoveAliasisAliasgetAliases
BeanDefinitionRegistry:Bean定义注册器,提供了registerBeanDefinitionremoveBeanDefinition
SingletonBeanRegistry:单例注册器,方法:registerSingletoncontainsSingleton

命名习惯03
默认实现,在Abstract***之后,使用了Default前缀

如:DefaultConversionServiceDefaultListableBeanFactoryDefaultNamespaceHandlerResolver

命名习惯04
当一个类有层级概念(表明该类在处理时需要考虑父级情况)时,会定义一个前缀:`HierarchicalXxx` 的类,这个类内部的方法会涉及到:`setParent`,`getParent`,如:

HierarchicalBeanFactory:有内部方法,getParentcontainsLocalBean
HierarchicalMessageSource:有内部方法,setParentMessageSourcegetParentMessageSource

命名习惯05
对于加载的命名,使用的是 `XxxLoader`,如:

ContextLoader:上下文加载(web 应用的时候)
ResourceLoader:资源加载的时候
DocumentLoader:加载 XML 文档

仅总结上述,掌握了Spring的命名规范后(实际只在核心功能类——基础context/beanfactory 中常见,后续其他类命名未见强制以上规范),在阅读源码过程中,就不会因为各种命名导致思绪混乱,比如:
看到ConfigurableXxx的类,就知道它是主管设置的入口,看到getParent,就知道对应的类应该是继承了HierarchicalXxx

如:在AbstractBeanFactory方法:getMergedBeanDefinition中,有如下一段代码,在进行分析的过程中,依据命名规范,我们可以比较清晰地理解获取过程

try {
    parentBeanName = transformedBeanName(bd.getParentName());
    if (!beanName.equals(parentBeanName)) {
        // 递归获取合并后的父定义,出口是:getParentName == null (即上述 if)
        pbd = getMergedBeanDefinition(parentBeanName);
    }
    else {        
        // 这里处理的情况是,子 beanName 与 父 beanName 相同!
        // 在一般情况下,如果我们在同一个 xml 文件中,定义了两个相同的 beanName,是会抛异常的,
        // 但这里却有处理 beanName 相同的情况
        // 此时就需要回顾,BeanFactory 有子类 HierarchicalBeanFactory,这种工厂具有层级关系,
        // 而 BeanName 可以相同,且 beanName 分属父子,在同一层级的 BeanFactory,即使父子关系,同名也会异常
        // 所以,这里就需要上溯父级工厂,去父级工厂就行递归 parentName 的 Bean定义(只有在父级工厂,才允许由相同名称的 beanName)
        // 而父级工厂为什么要判断是 ConfigurableBeanFactory 呢?
        // 因为 beanName 的设置入口,由 ConfigurableBeanFactory 提供,如果不是此种类型,那在 Spring 体系中,是不允许的(不规范的)
        BeanFactory parent = getParentBeanFactory();
        if (parent instanceof ConfigurableBeanFactory) {
            pbd = ((ConfigurableBeanFactory) parent).getMergedBeanDefinition(parentBeanName);    // 从父工厂开始继续递归 Bean定义
        }
        else {
            throw new NoSuchBeanDefinitionException(parentBeanName,
                    "Parent name '" + parentBeanName + "' is equal to bean name '" + beanName +
                    "': cannot be resolved without a ConfigurableBeanFactory parent");
        }
    }
}

再,我们平时的使用中,常常会执行(BeanFactory)ApplicationContext
来强转并使用BeanFactory的方法getBean获取单例,就规范而言,是因为BeanFactory是作为获取的入口。
常见的继承关系有:
DefaultXxx --> 继承 AbstractXxx --> 继承 ConfigurableXxx --> Xxx
这样,最终子类将拥有设置与获取的方法。
了解一些命名约束,有助于更好地理解源码本义,以上均为个人阅后感,如有错误,还请指正。

你可能感兴趣的