两全其美的

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

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

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

siQNe3MEh6TA9QAKcIUf1lA

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

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

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

抽象文件模式

swd-IduLEylpsrxRH_ZLVxQ

此模型中的文档类似于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);}@Overridepublic final Object put(String key, Object value) {return entries.put(key, value);}@Overridepublic final Object get(String key) {return entries.get(key);}@Overridepublic 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 Documentfinal Number num = (Number) get(PRICE); return num == null? OptionalInt.empty(): OptionalInt.of(num.intValue());}
}

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

汽车.java

public final class Car extends BaseDocumentimplements 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结构安全。可以通过多个接口从多个位置修改组件，这可能会使代码的可测试性降低。因此，在大规模实施此模式之前，应权衡利弊。