为对象的类型做强制转换是一种非常不好的设计。但在某些情况下，我们没有其他选择。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 转型的测试结果，与静态转型的结果是完全一致的。

　　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的。
　　你怎么认为的呢？你自己会使用这些方法吗？