两全其美的

使用抽象文档模式的类型安全视图

您如何组织对象？ 在本文中，我将介绍一种模式，该模式以无类型的方式在您的系统中组织所谓的名词类，然后使用特征公开数据的类型化视图。 这使得只需少量的牺牲就可以在Java之类的语言中获得JavaScript之类的非类型语言的灵活性。

用户在用户界面中所做的每种配置，表单中的每种选择都需要存储在可从应用程序访问的某个位置。 它需要以一种可以操作的格式存储。 教科书中的示例是为系统中每个名词定义类，并为它们所包含的字段使用getter和setter方法。 做教科书模型的一种更为严肃的方法是为每个名词定义企业bean，并使用注释对其进行处理。 它可能看起来像这样：

这些静态模型有局限性。 随着系统的发展，您将需要添加更多字段，更改组件之间的关系，并可能出于不同目的创建其他实现。 你知道这个故事。 突然，每个名词的静态成分不再那么有趣了。 因此，您开始研究其他开发人员。 他们如何解决这个问题？ 在JavaScript等非类型化语言中，您可以使用地图来解决此问题。 有关组件的信息可以存储为键值对。 如果一个子系统需要存储一个附加字段，则可以这样做，而无需事先定义该字段。

var myCar = {model: "Tesla", color: "Black"};
myCar.price = 80000; // A new field is defined on-the-fly

它加快了发展速度，但同时付出了巨大的代价。 您会失去类型安全性！ 每个真正的Java开发人员的噩梦。 由于您没有使用组件的结构，因此测试和维护也更加困难。 在Speedment进行的最近一次重构中，我们面对静态设计与动态设计的这些问题，并提出了一个称为Abstract Document Pattern的解决方案。

抽象文件模式

此模型中的文档类似于JavaScript中的Map。 它包含许多未指定值类型的键值对。 在这个未类型化的抽象文档之上，是许多Traits ，它们表示一个类的特定属性。 特征已使用类型化的方法来检索它们表示的特定值。 名词类只是原始文档接口的抽象基础实现之上的不同特征的并集。 因为一个类可以从多个接口继承，所以可以这样做。

实作

让我们看一下这些组件的来源。

Document.java

public interface Document {
    Object put(String key, Object value);

    Object get(String key);

    <T> Stream<T> children(
            String key,
            Function<Map<String, Object>, T> constructor
    );
}

BaseDocument.java

public abstract class BaseDocument implements Document {

    private final Map<String, Object> entries;

    protected BaseDocument(Map<String, Object> entries) {
        this.entries = requireNonNull(entries);
    }

    @Override
    public final Object put(String key, Object value) {
        return entries.put(key, value);
    }

    @Override
    public final Object get(String key) {
        return entries.get(key);
    }

    @Override
    public final <T> Stream<T> children(
            String key,
            Function<Map<String, Object>, T> constructor) {

        final List<Map<String, Object>> children = 
            (List<Map<String, Object>>) get(key);

        return children == null
                    ? Stream.empty()
                    : children.stream().map(constructor);
    }
}

HasPrice.java

public interface HasPrice extends Document {

    final String PRICE = "price";

    default OptionalInt getPrice() {
        // Use method get() inherited from Document
        final Number num = (Number) get(PRICE); 
        return num == null
            ? OptionalInt.empty()
            : OptionalInt.of(num.intValue());
    }
}

在这里，我们只公开获取价格的吸气剂，但是您当然可以用相同的方法实现一个吸气剂。 这些值始终可以通过put（）方法进行修改，但是您面临着将值设置为不同于getter期望的类型的风险。

汽车.java

public final class Car extends BaseDocument
        implements HasColor, HasModel, HasPrice {

    public Car(Map<String, Object> entries) {
        super(entries);
    }

}

如您所见，最终的名词类很少，但是您仍然可以使用类型化的吸气剂访问颜色，型号和价格字段。 向组件添加新值就像将其放入地图一样容易，但是除非它是接口的一部分，否则它不会公开。 该模型还适用于分层组件。 让我们看一下HasWheels特性的外观。

HasWheels.java

public interface HasWheels extends Document {
    final String WHEELS = "wheels";

    Stream<Wheel> getWheels() {
        return children(WHEELS, Wheel::new);
    }
}

就是这么简单！ 我们利用以下事实：在Java 8中，您可以将对象的构造函数作为方法引用来引用。 在这种情况下，Wheel类的构造函数仅采用一个参数Map <String，Object>。 这意味着我们可以将其称为Function <Map <String，Object>，Wheel>。

结论

这种模式既有优点，也有缺点。 随着系统的扩展，文档结构易于扩展和构建。 不同的子系统可以通过特征接口公开不同的数据。 根据使用哪个构造函数生成视图，可以将同一地图视为不同类型。 另一个优势是，整个对象层次结构都存在于一个Map中，这意味着可以使用现有的库（例如Google的gson工具 ）轻松进行序列化和反序列化。 如果希望数据是不可变的，则只需将内部映射包装在构造函数中的unmodifiableMap（）中，即可保护整个层次结构。

一个缺点是它不如常规的bean结构安全。 可以通过多个接口从多个位置修改组件，这可能会使代码的可测试性降低。 因此，在大规模实施此模式之前，应权衡利弊。

• 如果要查看实际的抽象文档模式示例，请查看Speedment项目的源代码，其中该项目管理有关用户数据库的所有元数据。

翻译自: https://www.javacodegeeks.com/2016/02/the-best-of-both-worlds.html