Java 扩展从XML模式生成的类是否安全？_Java_Oop_Schema

Java 扩展从XML模式生成的类是否安全？

java oop

Java 扩展从XML模式生成的类是否安全？,java,oop,schema,Java,Oop,Schema,假设我有一个（非常）简化的XML模式： <xsd:complexType name="Person"> <xsd:sequence> <xsd:element ref="FirstName"/> <xsd:element ref="FamilyName"/> </xsd:sequence> </xsd:complexType> 这个类闻起来非常像一个，我想给它添加一些行为。对我来说，扩展它似乎是最明

假设我有一个（非常）简化的XML模式：

<xsd:complexType name="Person">
  <xsd:sequence>
    <xsd:element ref="FirstName"/>
    <xsd:element ref="FamilyName"/>
  </xsd:sequence>
</xsd:complexType>

这个类闻起来非常像一个，我想给它添加一些行为。对我来说，扩展它似乎是最明显的解决方案，但我能始终指望这样的Java类能够安全地扩展吗？这样做总是安全的吗

一个相关的问题：如何命名扩充类？您会给它起一个与原始类相同的名字，但在另一个包中吗？你会称之为类似于MyPerson的东西吗？

将自动生成的代码与手工制作的代码混合在一起总是会有麻烦。如果改变了模式并重新生成了类，则您自己的自定义类将中断

我会避免扩展自动生成的类。如果您确实需要向它添加功能，那么更喜欢组合而不是继承。这意味着创建一个MyPerson类，其中包含一个人作为字段对象。如果修改xml模式并重新生成Person类，则MyPerson类将再次中断，但：

通过精心设计，突破性的更改不会影响MyPerson类之外的代码。如果您选择继承并且一个方法更改了它的名称，那么您将需要在类的所有调用方中进行更改
修复中断的更改将更容易。编译器将为您提供缺少的方法的清晰描述

将自动生成的代码与手工制作的代码混合在一起总是有麻烦的味道。如果改变了模式并重新生成了类，则您自己的自定义类将中断

通过精心设计，突破性的更改不会影响MyPerson类之外的代码。如果您选择继承并且一个方法更改了它的名称，那么您将需要在类的所有调用方中进行更改
修复中断的更改将更容易。编译器将为您提供缺少的方法的清晰描述

如果你想做这类事情，我建议你仔细看一下

EMF工具集可以使用XSD提取EMF模型，然后生成Java类您可以修改生成的类，只要遵循一个简单的规则，在更改XSD/模型并重新生成类时，您的修改不会丢失

生成的代码中的每个可修改成员声明前面都有一条Java注释，该注释将该成员标记为已生成。如果要修改成员，请删除此注释并进行更改。下次重新生成时，生成器将对每个类的旧版本和新版本逐个执行成员比较，查找签名匹配的成员，并根据“旧”版本中是否存在“生成的”标记注释进行更新。这项工作出人意料地好。您有时需要进行一些手动调整（例如，删除不再需要的导入），但只要您记住删除标记注释，您就不会丢失更改。（但无论如何，签入生成的代码是个好主意……如果只是为了控制更改的版本！）

如果您不喜欢EMF生成的代码，您可以在模型的相关GenModel中调整许多代码生成选项，或者可以修改或替换组成EMF源代码生成器的JET模板

除了生成表示内存中XML的类之外，EMF还为您的数据结构提供了一个XML序列化器/反序列化器和一个可扩展/可定制的基于GUI的编辑器。相关的EMF项目包括将数据持久化到数据库中的工具，通过验证规则、事务、查询和比较来增强模型。在相关的Eclipse建模项目中还有更多的内容

页面上有一大堆白皮书、教程和其他文档

如果你想做这类事情，我建议你仔细看看

如果您不喜欢EMF生成的代码，您可以在模型的相关GenModel中调整许多代码生成选项，或者可以修改或替换组成EMF源代码生成器的JET模板

除了生成表示内存中XML的类之外，EMF还为您的数据结构提供了一个XML序列化器/反序列化器和一个可扩展/可定制的基于GUI的编辑器。相关的EMF项目包括用于将数据持久化到数据库中的工具，使用验证规则、事务、查询和数据扩展模型

public class Person {
  protected FirstName firstName;
  protected FamilyName familyName;

  // and the usual getters and setters
}