从开源代码学习JAVA基础之继承体系

从开源代码学习JAVA基础之继承体系

类图

知识点

一般来说我们说继承的时候，脑子里想到的是肯定不会是这样一张图。想到的首先可能是会飞的和会叫的鸭子，head first设计模式的例子。给一个类插上不同的功能的接口。
但其实，那只是很简单的一种情况。
这里的案例，是mapreduce包中重构了mapred的api之后的类图。可以看出来，新版本的mapreduce的一些倾向性

• 更偏向使用抽象类来提供默认实现，这样方便修改默认行为
• 喜欢使用context，来提供全面的上下文

这里有意思的是，机会每一层的实现类，都继承自一个父类和一个接口，每一个接口都有一个默认实现类。类的继承体系和接口的继承体系相对称。其实，每一层是有递进关系的，使用的时候，也是。MRAppMaster中更多使用JobContext，而Mapper中更多使用MapContext。所以这里每一层的实现类除了提供了默认实现，还提供了user facing的功能。
那是不是只提供左侧的抽象类体系就够了呢，当然不是，右侧的接口体系的作用是使得代码更容易替换新的实现类，这也是接口的基本优点，面向抽象编程。

设计类图的时候
确定好user facing的体系
面向抽象编程

因为有user facing的问题，所以需要好好设计类图，如果让每个类插满了interface，优点就是每个类都是按照需要组合的interface，缺点就是，会出现大量的instance of的转换，不方便统一编程，需要根据定制的interface来完成调用过程。

user facing 和 可插拔interface集成体系

比如下面Partitioner左侧的体系是新版本api，右侧是兼容旧的api

虽然说新版的api倾向使用抽象类，这样可以提供默认实现，和实现模板模式，但是个人觉得没必要把Configurable完全抽离出去，这样的话，虽然说不需要Conf的Paritioner可以不带有相关函数，但是也给实例化Paritioner增加了麻烦，如下，可以看到，反射生成Paritioner的时候，需要传入Conf，然后判断目标Paritioner是不是需要Conf，然后进行相关的设置。所以如果碰到这种user facing，然后提供的是抽象类的情况，子类存在插了不同interface的变种，就会导致出现instance of的需求来进行相关调用或者初始化。
所以提供一个集大成的接口或者抽象类作为user facing更好。然后就是抽象类更具有平台定制的能力，提供默认行为或者模板模式。
这里把Configurable抽象成一个接口，可以学习下，更大的作用是让结构清晰，更容易微操。

    NewOutputCollector(org.apache.hadoop.mapreduce.JobContext jobContext,
                       JobConf job,
                       TaskUmbilicalProtocol umbilical,
                       TaskReporter reporter
                       ) throws IOException, ClassNotFoundException {
      collector = createSortingCollector(job, reporter);
      partitions = jobContext.getNumReduceTasks();
      if (partitions > 1) {
        partitioner = (org.apache.hadoop.mapreduce.Partitioner<K,V>)
          ReflectionUtils.newInstance(jobContext.getPartitionerClass(), job);
      } else {
        partitioner = new org.apache.hadoop.mapreduce.Partitioner<K,V>() {
          @Override
          public int getPartition(K key, V value, int numPartitions) {
            return partitions - 1;
          }
        };
      }
    }

  public static <T> T newInstance(Class<T> theClass, Configuration conf) {
    T result;
    try {
      Constructor<T> meth = (Constructor<T>) CONSTRUCTOR_CACHE.get(theClass);
      if (meth == null) {
        meth = theClass.getDeclaredConstructor(EMPTY_ARRAY);
        meth.setAccessible(true);
        CONSTRUCTOR_CACHE.put(theClass, meth);
      }
      result = meth.newInstance();
    } catch (Exception e) {
      throw new RuntimeException(e);
    }
    setConf(result, conf);
    return result;
  }

  public static void setConf(Object theObject, Configuration conf) {
    if (conf != null) {
      if (theObject instanceof Configurable) {
        ((Configurable) theObject).setConf(conf);
      }
      setJobConf(theObject, conf);
    }
  }

来看一个简单的接口增加更能的情况，让类实现一个接口，便赋予了一项能力。

ToolRunner.java

  public static int run(Configuration conf, Tool tool, String[] args) 
    throws Exception{
    if (CallerContext.getCurrent() == null) {
      CallerContext ctx = new CallerContext.Builder("CLI").build();
      CallerContext.setCurrent(ctx);
    }
    
    if(conf == null) {
      conf = new Configuration();
    }
    GenericOptionsParser parser = new GenericOptionsParser(conf, args);
    //set the configuration back, so that Tool can configure itself
    tool.setConf(conf);
    
    //get the args w/o generic hadoop args
    String[] toolArgs = parser.getRemainingArgs();
    return tool.run(toolArgs);
  }

Tool.java

public interface Tool extends Configurable {
  /**
   * Execute the command with the given arguments.
   * 
   * @param args command specific arguments.
   * @return exit code.
   * @throws Exception
   */
  int run(String [] args) throws Exception;
}

早期的WordCount.java

public class WordCount extends Configured implements Tool {
    public static void main(String[] args) throws Exception {
    int res = ToolRunner.run(new Configuration(), new WordCount(), args);
    System.exit(res);
  }

这里，然后类实现了Tool接口，那就拥有了被ToolRunner调用的能力。然后这里WordCount是直接user facing的所以这样直接实现接口，不用担心抽象的问题。