Java 8类型转换(及改进?)

发表于:2015-8-14 09:26

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:paddx    来源:51Testing软件测试网采编

  为对象的类型做强制转换是一种非常不好的设计。但在某些情况下,我们没有其他选择。Java自诞生的那一天起,就具备这种功能。
  我认为Java 8在一定程度改善了这项古老的技术。
  静态转型
  Java中最常用的转型方式如下:
  静态转型
  Object obj; // may be an integer
  if (obj instanceof Integer) {
  Integer objAsInt = (Integer) obj;
  // do something with 'objAsInt'
  }
  这里使用了 instanceof 和转型操作符,这些操作符已经融入到语言当中了。对象转换的类型(这个例子中是Integer)必须是在编译期静态确定的,所以我们将这种转型称为静态转型。
  如果obj不是Integer,上面的测试就会失败。如果我们以任何方式做类型转换,就会得到一个 ClassCastException 异常。如果obj是null,intanceof 测试会失败,但是转型是可以通过的,因为null可以被任何类型引用。
  动态转型
  有一种不常见的技术,即使用Class的方法,这些方法与上面的操作符的作用是一致的。
  动态转换成已知类型
  Object obj; // may be an integer
  if (Integer.class.isInstance(obj)) {
  Integer objAsInt = Integer.class.cast(obj);
  // do something with 'objAsInt'
  注意,这个例子中类型的转换也是在编译期确定的,所以没有必要这么去做。
  动态转型
  Object obj; // may be an integer
  Class<T> type = // may be Integer.class
  if (type.isInstance(obj)) {
  T objAsType = type.cast(obj);
  // do something with 'objAsType'
  }
  因为转换的类型在编译期是不知道,所以我们将这种转型称之为动态转型。
  对错误类型和 null 转型的测试结果,与静态转型的结果是完全一致的。
  casting-java-8-and-beyond
  Stream及Optional的转型
  现在
  对 Optional 中的值或 Stream 中的元素转型需要两个步骤:第一步,我们需要过滤掉错误的类型,然后我们需要将其转换为目标类型。
  Optional中的转型
  Optional<?> obj; // may contain an Integer
  Optional<Integer> objAsInt = obj
  .filter(Integer.class::isInstance)
  .map(Integer.class::cast);
  我们需要两个步骤来完成转型,这虽然不是什么大问题,但是我感觉还是有一点笨拙和冗余。
  未来(可能)
  我建议Class的强制转型方法能返回一个 Optional 或者 Stream。如果传递的对象的类型是正确的,则返回一个包含该对象的Optional或Stream。否则返回的Optional或Stream不包含任何元素。
  这些方法的实现比较琐碎:
  Class上的新方法
  public Optional<T> castIntoOptional(Object obj) {
  if (isInstance(obj))
  return Optional.of((T) obj);
  else
  Optional.empty();
  }
  public Stream<T> castIntoStream(Object obj) {
  if (isInstance(obj))
  return Stream.of((T) obj);
  else
  Stream.empty();
  }
  我们可以使用 flatMap 一步完成过滤和强制转换:
  FlatMap的实现:
  Stream<?> stream; // may contain integers
  Stream<Integer> streamOfInts = stream.
  flatMap(Integer.class::castIntoStream);
  错误的实例类型或者null引用,在实例测试的时候会失败,所以返回空的 Optional 或 Stream。这种方式永远不会抛出 ClassCastException 异常。
  成本和收益
  我们怎么来衡量这些方法是否真正有用呢?
  有多少代码真正会使用它们?
  对于一个中等水平的开发者来说,它们是否能提高代码的可读性?
  是否值得为其节约一行代码?
  实现和维护它们的成本是多少?
  我对这些问题的回答是:不多,是非常少。所以,这是一个总和趋近于0的游戏,但是,我可以证明虽然收益不多,但却是大于0的。
  你怎么认为的呢?你自己会使用这些方法吗?
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号