Java

作者的原标题是<Prefer class hierarchies to tagged classes>，即用类层次优于tagged class。

我不知道有没有tagged class这么一说，其实作者指的tagged class的是一个类描述了多种抽象，可以根据某个field决定不同的实例。
下面是书中例子，使用shape和部分表示长度的field构成形状并计算面积，脑补一下什么是tagged class：

class Figure {
    enum Shape {
        RECTANGLE, CIRCLE
    };

    // Tag field - the shape of this figure
    final Shape shape;

    // These fields are used only if shape is RECTANGLE
    double length;
    double width;

    // This field is used only if shape is CIRCLE
    double radius;

    // Constructor for circle
    Figure(double radius) {
        shape = Shape.CIRCLE;
        this.radius = radius;
    }

    // Constructor for rectangle
    Figure(double length, double width) {
        shape = Shape.RECTANGLE;
        this.length = length;
        this.width = width;
    }

    double area() {
        switch (shape) {
        case RECTANGLE:
            return length * width;
        case CIRCLE:
            return Math.PI * (radius * radius);
        default:
            throw new AssertionError();
        }
    }
}

不难看出这个类想传达什么信息，也不难看出这样的方式有很多缺陷。
虽然能看懂是什么意思，但由于各种实现挤在一个类中，其可读性并不好。
不同的实现放到一个类里描述，即会根据实现的不同而使用不同的field，即，field无法声明为final。(难道要在构造器里处理不用的field?)
虽然微不足道，内存确实存在毫无意义的占用。
不够OO。

虽然上一篇把类层次说得一无是处，其实类层次就是用来解决这一问题的，而上面的tagged class是用非OO的方式模仿类层次。
将tagged class转为类层次，首先要将tagged class里的行为抽象出来，并为其提供抽象类。
以上面的Figure为例，我们之需要一个方法——area。
接下来需要为每一个tag定义具体子类，即例子中的circle和rectangle。
然后为子类提供相应的field，即circle中的radius和rectangle的width、length。
最后为子类提供抽象方法的相应实现。
其实都不用这样去说明转换步骤，因为OO本身就是很自然的东西。

转换结果如下：

abstract class Figure {
    abstract double area();
}


class Circle extends Figure {
    final double radius;

    Circle(double radius) {
        this.radius = radius;
    }

    double area() {
        return Math.PI * (radius * radius);
    }
}

class Rectangle extends Figure {
    final double length;
    final double width;

    Rectangle(double length, double width) {
        this.length = length;
        this.width = width;
    }

    double area() {
        return length * width;
    }
}

class Square extends Rectangle {
    Square(double side) {
        super(side, side);
    }
}

这样做的好处显而易见，
代码简单清晰，没有样板代码；
类型相互独立，不会受到无关field的影响，field可以声明为final。
子类行可以独立进行扩展，互不干扰。

回到最初的tagged class，它真的就一无是处？
如果使用这个类，我只需要在调用构造器时使用相应的参数就可以得到想要的实例。
就像策略模式那样。
当然，tagged class也许可能算是策略模式(传递的应该是某个行为的特征，而不是实例特征)，但策略模式在Java中并不是这样使用。

通常，一个策略是通过调用者通过传递函数来指定特定的行为的。
但Java是没有函数指针的，所以我们用对象引用实现策略模式，即调用该对象的方法。
对于这种仅仅作为一个方法的"载体"，即实例等同与方法指针的对象，作者将其称为函数对象(function object)。

举个例子，比如我们有这样的一个具体策略(concrete strategy)：

class StringLengthComparator {
    private StringLengthComparator() {
    }

    public static final StringLengthComparator INSTANCE = new StringLengthComparator();

    public int compare(String s1, String s2) {
        return s1.length() - s2.length();
    }
}

具体策略的引用可以说是一个函数指针。
对具体策略再抽象一层即成为一个策略接口(strategy interface)。
对于上面的例子，java.util中正好有Comparator：

public interface Comparable<T> {

    int compare(T o1, T o2);

    boolean equals(Object obj);
}

于是，我们使用的时候可能会用匿名类传递一个具体策略：

Arrays.sort(stringArray, new Comparator<String>() {
    public int compare(String s1, String s2) {
        return s1.length() - s2.length();
    }
});

用代码描述似乎是那么回事，我只是在我想使用的地方传递了一个具体策略。
缺点很明显——每次调用的时候又需要创建一个实例。
但又能怎么做? 把每个可能用到的具体策略在某个Host类里实现策略接口后都做成field并用final声明?
感觉很傻，但确实可以考虑，因为这样做还有其他好处。
比如，相比匿名类，具体策略可以有更直观的命名，而且具体策略可以实现其他接口。

代码如下：

// Exporting a concrete strategy
class Host {
    private static class StrLenCmp
        implements Comparator<String>, Serializable {
            public int compare(String s1, String s2) {
                return s1.length() - s2.length();
            }
    }

    // Returned comparator is serializable
    public static final Comparator<String> STRING_LENGTH_COMPARATOR = new StrLenCmp();

    ... // Bulk of class omitted
}