泛型（16）：对缺乏潜在类型机制的补偿

野性酷女 2023-05-28 06:46 1阅读 0赞

尽管java不支持潜在类型机制，但是这并不意味着有界泛型代码不能在不同的类型层次结构之间应用。也就是说，我们仍旧可以创建真正的泛型代码，但是这需要付出一些额外的努力。

### 一、反射 ###

可以使用的一种方式是反射，下面的perform()方法就是用了潜在类型机制：

import java.lang.reflect.Method;
    
    /**
     * 演员
     */
    class Mime {
    
    	// 逆风而行
    	public void walkAgainstTheWind() {
    	}
    
    	// 假装坐下
    	public void sit() {
    		System.out.println("Pretending to sit");
    	}
    
    	// 无形的墙
    	public void pushInvisibleWalls() {
    	}
    
    	public String toString() {
    		return "Mime";
    	}
    }
    
    /**
     * 聪明的狗
     */
    class SmartDog {
    	public void speak() {
    		System.out.println("woof");
    	}
    
    	public void sit() {
    		System.out.println("Sitting");
    	}
    
    	// 繁殖
    	public void reproduce() {
    	}
    }
    
    class CommunicateReflectively {
    	public static void perform(Object speaker) {
    		Class<?> spkr = speaker.getClass();
    		try {
    			try {
    				Method speak = spkr.getMethod("speak");
    				speak.invoke(speaker);
    			} catch (NoSuchMethodException e) {
    				System.out.println(speaker + " cannot speak");
    			}
    			try {
    				Method sit = spkr.getMethod("sit");
    				sit.invoke(speaker);
    			} catch (NoSuchMethodException e) {
    				System.out.println(speaker + " cannot sit");
    			}
    		} catch (Exception e) {
    			throw new RuntimeException(speaker.toString(), e);
    		}
    	}
    }
    
    public class LatentReflection {
    	public static void main(String[] args) {
    		CommunicateReflectively.perform(new SmartDog());
    		CommunicateReflectively.perform(new Robot());
    		CommunicateReflectively.perform(new Mime());
    	}
    }

上例中，这些类完全是彼此分离的，没有任何公共基类（除了Object）或接口。通过反射，CommunicateReflectively.perform()能够动态地确定所需要的方法是否可用并调用它们。它甚至能够处理Mime只具有一个必需的方法这一事实，并能够部分实现其目标。

### 二、将一个方法应用于序列 ###

反射提供了一些有趣的可能性，但是它将所有的类型检查都转移到了运行时，因此在许多情况下并不是我们所希望的。如果能够实现编译期类型检查，这通常会更符合要求。但是有可能实现编译期类型检查和潜在类型机制吗？

让我们看一个说明这个问题的示例。假设想要创建一个apply()方法，它能够将任何方法应用于某个序列中的所有对象。这是接口看起来并不适合的情况，因为你想要将任何方法应用于一个对象集合，而接口对于描述“任何方法”存在过多的限制。如何用java来实现这个需求呢？

最初，我们可以用反射来解决这个问题，由于有了java SE5的可变参数，这种方式被证明是相当优雅的：

import java.lang.reflect.Method;
    import java.util.ArrayList;
    import java.util.List;
    
    class Apply {
    	public static <T, S extends Iterable<? extends T>> void apply(S seq, Method f, Object... args) {
    		try {
    			for (T t : seq) {
    				f.invoke(t, args);
    			}
    		} catch (Exception e) {
    			throw new RuntimeException(e);
    		}
    	}
    }
    
    class Shape {
    	public void rotate() {
    		System.out.println(this + "rotate");
    	}
    
    	public void resize(int newSize) {
    		System.out.println(this + " resize " + newSize);
    	}
    }
    
    class Square extends Shape {
    }
    
    class FilledList<T> extends ArrayList<T> {
    	public FilledList(Class<? extends T> type, int size) {
    		try {
    			for (int i = 0; i < size; i++) {
    				add(type.newInstance());
    			}
    		} catch (Exception e) {
    			throw new RuntimeException(e);
    		}
    	}
    }
    
    public class ApplyTest {
    	public static void main(String[] args) throws NoSuchMethodException, SecurityException {
    		List<Shape> shapes = new ArrayList<Shape>();
    		for (int i = 0; i < 10; i++) {
    			shapes.add(new Shape());
    		}
    		Apply.apply(shapes, Shape.class.getMethod("rotate"));
    		Apply.apply(shapes, Shape.class.getMethod("resize", int.class), 5);
    		Apply.apply(new FilledList<Shape>(Shape.class, 10), Shape.class.getMethod("rotate"));
    		Apply.apply(new FilledList<Shape>(Square.class, 10), Shape.class.getMethod("rotate"));
    
    		SimpleQueue<Shape> ShapeQ = new SimpleQueue<>();
    		for (int i = 0; i < 5; i++) {
    			ShapeQ.add(new Shape());
    			ShapeQ.add(new Square());
    		}
    	}
    }

在Apply中，我们运气很好，因为碰巧在java内建了一个由java容器类库使用的Iterable接口。正由于此，apply()方法可以接受任何实现了Iterable接口的事物，包括诸如List这样的所有Collection类。但是它还可以接受其他任何事物，只要能够使这些事物是Iterable的——例如，在main()中使用的下面定义的SimpleQueue类：

import java.util.Iterator;
    import java.util.LinkedList;
    
    public class SimpleQueue<T> implements Iterable<T> {
    
    	private LinkedList<T> storage = new LinkedList<>();
    
    	public void add(T t) {
    		storage.offer(t);
    	}
    
    	public T get() {
    		return storage.poll();
    	}
    
    	@Override
    	public Iterator<T> iterator() {
    		return storage.iterator();
    	}
    }

在Apply.java中，异常被转换为RuntimeException，因为没有多少办法可以从这种异常中恢复——在这种情况下，它们实际上代表着程序员的错误。

注意，我必须放置边界和通配符，以便使Apply和FilledList在所有需要的情况下都可以使用。可以试验一下，将这些边界和通配符拿出来，你就会发现某些Apply和FilledList应用将无法工作。

FilledList表示有点进退两难的情况。为了使某种类型可用，它必须有默认（无参）构造器，但是java没有任何方式可以在编译期断言这种事情，因此这就变成了一个运行时问题。确保编译期检查的常见建议是定义一个工厂接口，它有一个可以生成对象的方法，然后FilledList将接受这个接口而不是这个类型标记的“原生工厂”，而这样做的问题是在FilledList中使用的所有类都必须实现这个接口。稍后，我将展示一种使用适配器的解决方案。

但是上面所展示的使用类型标记的方法可能是一种合理的折中（至少是一种马上就能想到的解决方案）。通过这种方式，使用像FilledList这样的东西就会非常容易，我们会马上想到要使用它而不是会忽略它。当然，因为错误是在运行时报告的，所以你要有把握，这些错误将在开发过程的早期出现。

注意，类型标记技术是java文献推荐的技术，例如Gilad Bracha在他的论文《Generics in Java Programming Language》中写道“这是一种惯用法，例如，在操作注解的新API中得到了广泛的应用”。但是，我发现人们对这种技术的适应程度不一，有些人强烈地首选本章前面描述的工厂方式。

尽管java解决方案被证明很优雅，但是我们必须知道使用反射可能比非反射的实现要慢一些，因为有太多的动作都是在运行时发生的。这不应该阻止你使用这种解决方案的脚步，至少可以将其作为一种马上就能想到的解决方案（以防止陷入不成熟的优化中），但这毫无疑问是这两种方法之间的一个差异。

### 三、当你并未碰巧拥有正确的接口时 ###

上面的示例是受益的，因为Iterable接口已经是内建的，而它正式我们需要的。但是更一般的情况又会怎样呢？如果不存在刚好适合你的需求的接口呢？

例如，让我们泛化FilledList中的思想，创建一个参数化的方法fill()，它接受一个序列，并使用Generator填充它。当我们尝试着用java来编写时，就会陷入问题之中，因为没有任何像前面示例中Iterable接口那样的“Addable”便利接口。因此你不能说：“可以在任何事物上调用add()。”而必须说：“可以在Collection的子类型上调用add()。”这样产生的代码并不是特别泛化，因为它限制为只能工作于Collection实现。如果我试图使用没有实现Collection的类，那么我的泛化代码将不能工作。下面是这都代码的样子：

import java.util.ArrayList;
    import java.util.Collection;
    import java.util.List;
    
    class Fill {
    	public static <T> void fill(Collection<T> collection, Class<? extends T> classToken, int size) {
    		for (int i = 0; i < size; i++) {
    			try {
    				collection.add(classToken.newInstance());
    			} catch (Exception e) {
    				throw new RuntimeException(e);
    			}
    		}
    	}
    }
    
    class Contract {
    	private static long counter = 0;
    	private final long id = counter++;
    
    	public String toString() {
    		return getClass().getName() + " " + id;
    	}
    }
    
    class TitleTransfer extends Contract {
    }
    
    public class FillTest {
    	public static void main(String[] args) {
    		List<Contract> contracts = new ArrayList<>();
    		Fill.fill(contracts, Contract.class, 3);
    		Fill.fill(contracts, TitleTransfer.class, 2);
    		for (Contract c : contracts) {
    			System.out.println(c);
    		}
    		SimpleQueue<Contract> contractQueue = new SimpleQueue<>();
    //		contractQueue.fill(contractQueue, Contract.class, 3);
    	}
    }

这正是具有潜在类型机制的参数化类型机制的价值所在，因为你不会受到任何特定类库的创建者过去所作的设计决策的支配，因此不需要在每次碰到一个没有考虑到你的具体情况的新类库时，都去重写代码（因此这样的代码才是真正的“泛化的”）。在上面的情况中，因为java设计者（可以理解地）没有预见到对“Addable”接口的需要，所以我们被限制在Collection继承层次结构之内，即便SimpleQueue有一个add()方法，它也不能工作。因为这会将代码限制为只能工作于Collection，因此这样的代码不是特别“泛化”。有了潜在类型机制，情况就会不同了。

### 四、用适配器仿真潜在类型机制 ###

java泛型并不没有潜在类型机制，而我们需要像潜在类型机制这样的东西去编写能够跨类边界应用的代码（也就是“泛化”代码）。存在某种方式可以绕过这项限制吗？

潜在类型机制将在这里实现什么？它意味着你可以编写代码声明：“我不关心我在这里使用的类型，只要它具有这些方法即可。”实际上，潜在类型机制创建了一个包含所需方法的隐式接口。因此它遵循这样的规则：如果我们手工编写了必需的接口（因为java并没有为我们做这些事），那么他就应该能够解决问题。

从我们拥有的接口中编写代码来产生我们需要的接口，这是适配器设计模式的一个典型示例。我们可以使用适配器来适配已有的接口，以产生想要的接口。下面这种使用前面定义的Coffee继承结构的解决方案演示了编写适配器的不同方式：

import java.util.ArrayList;
    import java.util.Collection;
    import java.util.List;
    
    import com.buba.util.Generator;
    
    import generics.coffee.Coffee;
    import generics.coffee.Latte;
    import generics.coffee.Mocha;
    
    interface Addable<T> {
    	void add(T t);
    }
    
    class Fill2 {
    	public static <T> void fill(Addable<T> addable, Class<? extends T> classToken, int size) {
    		for (int i = 0; i < size; i++) {
    			try {
    				addable.add(classToken.newInstance());
    			} catch (Exception e) {
    				throw new RuntimeException(e);
    			}
    		}
    	}
    
    	public static <T> void fill(Addable<T> addable, Generator<T> generator, int size) {
    		for (int i = 0; i < size; i++) {
    			addable.add(generator.next());
    		}
    	}
    }
    
    class AddableCollectionAdapter<T> implements Addable<T> {
    
    	private Collection<T> c;
    
    	public AddableCollectionAdapter(Collection<T> c) {
    		this.c = c;
    	}
    
    	@Override
    	public void add(T t) {
    		c.add(t);
    	}
    }
    
    class Adapter {
    	public static <T> Addable<T> collectionAdapter(Collection<T> c) {
    		return new AddableCollectionAdapter<T>(c);
    	}
    }
    
    class AddableSimpleQueue<T> extends SimpleQueue<T> implements Addable<T> {
    	public void add(T item) {
    		super.add(item);
    	}
    }
    
    public class Fill2Test {
    	public static void main(String[] args) {
    		List<Coffee> carrier = new ArrayList<>();
    		Fill2.fill(new AddableCollectionAdapter<Coffee>(carrier), Coffee.class, 3);
    		Fill2.fill(Adapter.collectionAdapter(carrier), Latte.class, 2);
    		for (Coffee c : carrier) {
    			System.out.println(c);
    		}
    		System.out.println("-------------");
    		AddableSimpleQueue<Coffee> coffeeQueue = new AddableSimpleQueue<>();
    		Fill2.fill(coffeeQueue, Mocha.class, 4);
    		Fill2.fill(coffeeQueue, Latte.class, 1);
    		for (Coffee c : coffeeQueue) {
    			System.out.println(c);
    		}
    	}
    }

Fill2对Collection的要求与Fill不同，它只需要实现了Addable的对象，而Addable已经为Fill编写了——它是我希望编译器帮我创建的潜在类型的一种体现。

在这个版本中，我还添加了一个重载的fill()，它接受一个Generator而不是类型标记。Generator在编译期是类型安全的：编译器将确保传递的是正确的Generator，因此不会抛出任何异常。

第一个适配器，AddableCollectionAdapter，可以工作于基类型Collection，这意味着Collection的任何实现都可以使用。这个版本直接存储Collection引用，并使用它来实现add()。

如果有一个具体类型而不是继承结构的基类，那么当使用继承来创建适配器时，你可以稍微少编写一些代码，就像在AddableSimpleQueue中看到的那样。

在Fill2Test.main()中，你可以看到各种不同类型的适配器在运行。首先，Collection类型是由AddableCollectionAdapter适配的。这个第二个版本使用了一个泛化的辅助方法，你可以看到这个泛化方法是如何捕获类型并因此而不必显式地写出来的——这是产生更优雅的代码的一种惯用技巧。

接下来，使用了预适配的AddableSimpleQueue。注意，在两种情况下，适配器都允许前面没有实现Addable的类用于Fill2.fill()中。

使用像这样的适配器看起来是对缺乏潜在类型机制的一种补偿，因此允许编写出真正的泛化代码。但是，这是一个额外的步骤，并且是类库的创建者和消费者都必须理解的事物，而缺乏经验的程序员可能还没有能够掌握这个概念。潜在类型机制通过移除这个额外的步骤，使得泛化代码更容易应用，这就是它的价值所在。

**如果本文对您有很大的帮助，还请点赞关注一下。**