AdaptiveExtension

自适应Extension，作者其实在使用Extension方和Extension之间插入AdaptiveExtension用来自适应，也可以说是适配。

所以，我们发现，这里其实有三种，

1，一种是自动生成的Adaptive根据url参数来选择具体实现；

2，一种是自己实现一个Adaptive，写自己的逻辑选择具体实现，比如AdaptiveExtensionFactory，Compiler。这种都是在ExtensionLoader中需要使用，一般是不会这么做的。

3，还有一种没有Adaptive，实现一个adapter，比如TelnetHandler。这种因为不能根据url参数来决定使用哪一个实现。

从结构上看AdaptiveExtension是很重要的角色，我们配置了一些插件，但是具体使用哪一个如果用硬编码自然是不可能的，而这种自适应的方式得益于dubbo的状态数据信息都可以通过URL来获取，被叫做以URL为总线的模式。而自适应即是根据这些信息来决定调用哪一个插件的实现。

 

ExtensionLoader是插件机制的核心类:

private final Holder

以下方法都会触发loadFile，这个方法就会读取文件，解析出各个插件的class。有@Adaptive注解的会放入赋值给cachedAdaptiveClass。

下面以Transporter接口为例进行说明自动生成的代码:

@SPI("netty")public interface Transporter {    @Adaptive({Constants.SERVER_KEY, Constants.TRANSPORTER_KEY})    Server bind(URL url, ChannelHandler handler) throws RemotingException;     @Adaptive({Constants.CLIENT_KEY, Constants.TRANSPORTER_KEY})    Client connect(URL url, ChannelHandler handler) throws RemotingException;}

动态生成类：

public class Transporter$Adaptive implements Transporter {     public Server bind(URL arg0, ChannelHandler arg1) throws RemotingException {        URL url = arg0;        String extName = url.getParameter("server",                url.getParameter("transporter", "netty"));        Transporter extension = (Transporter) ExtensionLoader                .getExtensionLoader(Transporter.class).getExtension(extName);        return extension.bind(arg0, arg1);    } }

 

Adaptive机制是一个很好的设计，很好的解决多方案实现的适配问题，如果你遇到类似的代码架构的时候，多想一下更加有扩展性的设计。