Hadoop序列化中的工厂设计模式.docx

Hadoop 序列化中的工厂设计模式最近学习《Hadoop技术内幕》，简单研究了部分Hadoop源码。综合以前了解的一些开源项目，发现高端代码乍一看上去有一个共同特性：到处都是泛型，到处都是反射。直接打开一个方法的定义，基本找不到它的实现逻辑，只能找到接口。后来结合书上的介绍稍作了解，出现这种现象，说明源码很多都用到了抽象工厂模式。故再次查阅了抽象工厂的定义。相信这对于今后开发中定义一个优秀的架构是很有帮助的。抛出问题：Hadoop的序列化在Hadoop中有序列化的概念。简单搞清楚序列化：序列化是什么？就是把对象转化成二进制的流。反序列化就是把二进制流转化成对象。为什么要序列化？三点：持久化格式用于存储；通信数据格式用于传输；对象深拷贝；Hadoop中主要用前两点。为什么不用Java内建的序列化？Java序列化非常强大。序列化的时候把什么类描述，各种版本号，父类的信息都写到流中。一个简单的类能写出一大推数据来，对于强烈需要减少传输量提高效率的分布式计算就不适应。故Hadoop自己搞了一套。搞清楚了序列化的概念，然后再说一下有哪些东西需要序列化：Java中不是有个Serializable接口吗？同样：在hadoop中有Writable接口，实现Writable的类都是要序列化的类。简单举例几个：IntWritable，LongWritable，Text。在java中就是int，Long，String，只是在hadoop要适应新的序列化给改了。好了，那么Hadoop既然是java写的，不可能原来的序列化完全抛开不用了吧，所以原来的实现Serializable的也要序列化然后，序列化系列操作肯定有两个方法是相互依赖不可分割的：序列化和反序列化。那么总结一下：操作有两种：序列化和反序列化操作对象分两类：实现了Serializable的对象和实现了Writable的对象工厂系列的模式是干什么的？工厂类的模式，说穿了：调用一个工厂的工厂方法，可以产生诸多相互关联的对象。程序员灵活的选择创建哪个对象，这样就避免的在程序中反复创建各种对象，使创建对象和业务解耦，增加了程序的可扩展性。工厂系列模式的简单总结工厂系列的模式有：简单工厂；工厂方法；抽象工厂；应该说：越往下，越抽象，越解耦。简单总结下各工厂的实现，重点说hadoop中抽象工厂。为了使文档完整，对于1、2，我简单得列举了几个网上的例子，自己加了一点说明，没仔细分析，需有需要可再次上网有哪些信誉好的足球投注网站。简单工厂有三个元素：工厂类角色：具体类实现，用于判断要创建哪个产品对象抽象产品角色：一个抽象类或接口，为一系列相关产品的父类具体产品角色：一个或多个实现或继承抽象产品的具有共性的类简单例子：//抽象产品角色public interface Car{ public void drive(); } //具体产品角色public class Benz implements Car{ public void drive() { System.out.println(Driving Benz ); } } public class Bmw implements Car{ public void drive() { System.out.println(Driving Bmw ); } }//工厂类角色public class Driver{ //工厂方法//注意返回类型为抽象产品角色public static Car driverCar(String s)throws Exception { //判断逻辑，返回具体的产品角色给Client if(s.equalsIgnoreCase(Benz)) return new Benz(); else if(s.equalsIgnoreCase(Bmw)) return new Bmw(); ...... else throw new Exception(); ...... //欢迎暴发户出场...... public class Magnate{ public static void main(String[] args){ try{ //告诉司机我今天坐奔驰Car car = Driver.driverCar(benz); //下命令：开车car.drive(); ...... 这个例子我从网上抓下来的，先搞清楚什么是简单工厂模式，这里，他的缺点很明显：虽然业务与对象创建解耦了，但是具体工厂里涉及到了一部分业务，万一这部分判断比较复杂，这不仅写起来复杂麻烦，可扩展性还非常差，不实用工厂方法模式有四个元素：抽象产品和具体产品和简单