Java管理对象方法总结

有一天晚上我脑海中突然冒出来一个问题：“怎样管理我们代码中的对象”。

小弈是刚工作时的我，他说：通过 new 来创建一个对象然后直接使用就好了啊。

public class helloworld {

public void hello() {

system.out.println("hello world!");

}

}

helloworld helloworld = new helloworld();

helloworld.hello();

你们看，我有一个 helloworld 类，我用 new 就能直接创建一个对象，然后就能使用这个对象中所有的方法了，多简单啊。

二弈是工作两年的我，他一脸鄙视的对小弈说，你别整天 helloworld 好不好，还有啊，除了 new 你就不会其他的了，能不能有点追求啊？

小弈对二弈说那你说除了 new 还有什么办法啊？

二弈说可以通过 class 的 newinstance 或者 constructor 的 newinstance 来创建对象实例啊。

不过你得记住，class 的 newinstance 只能对那些拥有可见的(accessible)无参构造函数的类，才能进行对象的实例化，而 constructor 就没有这些限制。

大弈是工作三年的我，他说，虽然你们的方法都可以用来创建对象，但都还是手动创建的，太原始了，生产力太低。

工欲善其事，必先利其器，我们也得找个高效的生产力工具。ioc 容器你们了解吧？

以前我们在一个对象中如果要调用另外一个对象的方法时，都是通过 new 或者反射来手动创建该对象，但是每次都这样做太累了，并且类之间的耦合也很高。

通过 ioc 容器，我们可以把所有的对象交给容器来管理，在使用之前只需要定义一下对象，然后再使用到该对象时，ioc 容器就会帮我们把该对象初始化好，这样是不是更方便呢？

大弈说完，举了一个例子：

@bean

public class registerservice {

public void register() {

// do register

}

}

@bean

public class loginservice {

public void login() {

// do login

}

}

@bean

public class helloworld {

@autowired

private registerservice registerservice;

@autowired

private loginservice loginservice;

public void hello() {

// 注册

registerservice.register();

// ...

// 登录

loginservice.login();

}

}

ioc 容器通过一种叫 bean 的注解，在系统启动时扫描所有通过 bean 标注的类，对这些类进行实例化，然后将所有的对象都保存在容器中。再扫描所有通过 autowired 标注的属性或者方法，从容器中找到与之匹配(通过名称或者类型等)的对象将具体的对象赋值给这些属性。这样我们就可以直接将这些对象拿来使用了，作为一个伸手党是不是很幸福啊。

老弈是工作五年的我，他听了大弈的话后，提出了一个问题，对于新的项目可以使用这种 ioc 的容器，可是对于那些遗留的老项目来说，要使用 ioc 来改造是不太符合实情的。

我举个例子，在一个遗留的老项目中，有一个核心的接口 handler:

public interface handler<req, res> {

 res handle(req request);

}

handler 接口有很多的实现类，我们需要对不同的请求来调用不同的 handler 实现类进行处理，如果用 ioc 容器来管理这些实现类，显然不太合适，因为我们处理之前是不知道该用哪个 handler 实现类的。

大弈想了想，如果 handler 接口只有几个固定的实现类，并且在使用时只会使用一个来进行处理，那么倒是可以在启动前通过配置的方式来确定具体使用哪种 handler ，比如可以通过 @conditional 根据某些条件来确定加载具体的对象，但是这种要在使用时才能确定 handler 对象的类型确实比较棘手。

老弈看大家都不说话了，就继续说了下去。

为了要在调用方法时使用不同的 handler 来处理不同的而请求，需要确定两种类，一种是请求类，一种是处理类，并且要让请求类和处理类一一对应起来。

假设我们的请求类是一个 packet 类，每一个具体的请求类都继承自这个基类。

那么想要确定每一个具体的 packet 是什么类型的，可以有很多种方法，可以为每个 packet 取一个唯一的名字，例如：

public abstract class packet {

  public abstract string name();

}

也可以为每一个 packet 指定一个标志，例如：

public abstract class packet {

  public abstract int symbol();

}

但是不管哪种方式，每一个 packet 的实现类都需要实现抽象类中的方法，来“标志”自己是哪种 packet。

我们以第二种方式举例，假设我们有两个具体的 packet：

public class registerpacket extends packet {

// 注册所需要的其他参数

int symbol() {

return 1;

}

}

public class loginpacket extends packet {

// 登录所需要的其他参数

int symbol() {

return 2;

}

}

这样当我们接收到 request 对象时，通过调用 request.symbol() 就知道这个 request 是哪种类型的 packet 了，这时只要找到具体的 handler 实现类来处理就可以了。

那请求类已经可以确定了，怎样确定 handler 处理类呢？我们是否也可以在 handler 接口中定义一个 symbol 方法呢，像这样：

public interface handler<req, res> {

  int symbol();

  res handle(req request);

}

这样的话，只要在所有的实现类中实现 symbol 方法来标注该 handler 是用来处理何种 request 的即可。

public registerhandler implements handler<registerpacket, res> {

  int symbol(){

  return 1;

  }

  res handle(registerpacket request){

  // 具体的处理方法

  }

}

public loginhandler implements handler<loginpacket, res> {

  int symbol(){

  return 2;

  }

  res handle(loginpacket request){

  // 具体的处理方法

  }

}

最后把所有的 handler 实现类都实例化后保存在一个 handlerprovider 中，要使用时再到 handlerprovider 中来获取即可：

public interface handlerprovider {

  handler gethandler(int symbol);

}

那怎样获取到所有的 handler 的实现类呢，有两种方法。

一种是通过 serviceloader.load(handler.class) 的方式来获取，不过这种通过 spi 的方式需要在项目的 resources/meta-inf/services/ 目录下创建一个 xxx.handler 的文件，并在文件中将所有 handler 的实现类的完全类限定符列出来。

另一种比较简单的方式是通过扫描的方式，获取到所有 handler 的实现类。

到现在为止，我们的实现还算可以，但是有一个问题，那就是在 handler 接口中我们增加了一个方法，这样做就对原来的代码进行了侵入。

为了让原来的代码保持不变，我们可以定义一个注解来标注在所有的 handler 实现类上，比如这样：

@symbol(1)

public registerhandler implements handler<registerpacket, res> {

  res handle(registerpacket request){

  // 具体的处理方法

  }

}

@symbol(2)

public loginhandler implements handler<loginpacket, res> {

  res handle(loginpacket request){

  // 具体的处理方法

  }

}

这样就将 handler 的实现和标注进行了解耦了，也可以通过扫描 @symbol 注解来获取到所有的 handler 实现类，不过这样做的缺点就是假如我忘记对某个 handler 实现类添加 @symbol 注解，到时候就获取不到该 handler 了。

大家听完老弈的话之后，都陷入了沉思，我靠，还可以这么玩，真有趣。

这时候现在的我，也就是逅弈，说了一句，如果我有一个接口，他只有几个固定的实现类，我不想搞那一套那么重的实现方式，但是我也需要动态的获取实现类来对请求进行处理，那我该怎么办呢？

比如我有一个序列化的接口，如下所示：

public interface serializer {

  byte[] serialize(packet packet);

}

然后只有五种具体的序列化的实现类，如下所示：

public class jdkserializer implements serializer {

@override

  public byte[] serialize(packet packet) {

  // 具体的序列化操作

  }

}

public class fastjsonserializer implements serializer {

@override

  public byte[] serialize(packet packet) {

  // 具体的序列化操作

  }

}

public class hessianserializer implements serializer {

@override

  public byte[] serialize(packet packet) {

  // 具体的序列化操作

  }

}

public class kryoserializer implements serializer {

@override

  public byte[] serialize(packet packet) {

  // 具体的序列化操作

  }

}

public class protostuffserializer implements serializer {

@override

  public byte[] serialize(packet packet) {

  // 具体的序列化操作

  }

}

那么我们该怎么确定使用哪种序列化方式对参数 packet 进行序列化呢？

使用老弈刚刚说的那一套也确实能够实现，不过太麻烦了，又得对 packet 定义 symbol，又得对 hander 实现类进行标注，还得扫描所有的实现类。

我只有五个实现类，不需要搞那么麻烦的。

其实很简单，只需要定义一个枚举类，表示序列化的算法，然后对 packet 增加一个 algorithm 方法用来表示，使用何种序列化算法，如下所示：

public enum serializealgorithm {

  jdk((byte) 1),

  fast_json((byte) 2),

  hessian((byte) 3),

  kryo((byte) 4),

  proto_stuff((byte) 5);

  private byte type;

  serializealgorithm(byte type) {

    this.type = type;

  }

}

public abstract class packet implements serializable {

public abstract byte algorithm();

}

然后定义一个 serializerchooser 根据不同的算法选择不同的 serializer 实现类即可：

public interface serializerchooser {

  serializer choose(byte algorithm);

}

因为根据算法是可以知道对应的序列化接口的，所以就没有必要去扫描了，直接把几种序列化的实现类枚举出来即可，对象的实例可以使用单例模式，如下所示：

public class defaultserializerchooser implements serializerchooser {

  private defaultserializerchooser() {

  }

  public static serializerchooser getinstance() {

    return singleton.get(defaultserializerchooser.class);

  }

  @override

  public serializer choose(byte algorithm) {

    serializealgorithm serializealgorithm = serializealgorithm.getenum(algorithm);

    switch (serializealgorithm) {

      case jdk: {

        return singleton.get(jdkserializer.class);

      }

      case fast_json: {

        return singleton.get(fastjsonserializer.class);

      }

      case hessian: {

        return singleton.get(hessianserializer.class);

      }

      case kryo: {

        return singleton.get(kryoserializer.class);

      }

      case proto_stuff: {

        return singleton.get(protostuffserializer.class);

      }

      default: {

        return null;

      }

    }

  }

}

我说完后，大家又一次陷入了沉思，我知道大家都在思考，他们会在每一次思考中获得进步和成长，正如我在思考后得到成长一样。