从类图生成java类有意义吗？

Question

就像我们在开发之前进行设计和分析一样，从类图生成Java类不是很方便吗？

这将促进更详尽的设计和更好的规范，对吗？

奇怪的是，为什么Google返回大量工具从Java类生成类图，而不是反过来。

Answer 1

不，写代码比在电脑上画图表要快得多。要从图表中生成Java类，您必须绘制图表，然后输入大部分代码。当然，您可能不必键入get/set方法，但是隆布克在解决该问题方面做得更好。例如，简单地键入“类X实现Y”比绘制一个框、键入"X“、然后用正确的箭头将X连接到Y要容易得多。几十年来，我们一直在尝试从图表中生成代码，除了一些非常有限的域之外，它一直不受欢迎。

还可以看到这个问题。

Answer 2

我认为，在过去几年中，我倾向于使用类图来记录现有代码，而不是生成代码。

图表可以让读者快速查看系统的类和关系的总体结构。当然，图的成功使用取决于与代码保持同步的关系图；如果它们不同步，那么这些关系图就具有误导性。这就是为什么您看到从代码生成图表的工具。

从图表生成代码的感觉是如此的1990年代。它在Rational时代很流行，但我认为这种工具已经不再被广泛使用了。例如，通过输入(是的，通过使用代码辅助)，我可以比创建一个图表更快地编写代码。即使您制作了一个可以轻松绘制类图的工具，您是否也希望大多数程序员使用它呢？类图只能让您了解到这一点。您仍然需要编写代码来实现方法主体。什么样的软件会检查图表的一致性？从其他包导入类如何？谁能记得所有的符号，公共的，私人的，受保护的，包私有的？我们如何以方便的方式用下划线来表示静态成员？如果一个变量被初始化为一个复杂的表达式，我们如何输入它？即使它被输入，在图表工具中是否有一个编译器来检查我们有什么？

然后，一旦从图中生成代码，它完成的可能性有多大？我们还需要手工调整更多吗？如果是的话，如果我们在图表中发现一个错误怎么办？我们会失去我们的手编辑？

从图片或图表生成代码的整个想法似乎是一种误导的尝试，试图使软件工程像机械、电气或化学工程一样。甚至是建筑。在这些领域，你的“蓝图”是纸的设计，你的产品是用图纸制造的。软件不是那样的。在软件中，源代码是蓝图/设计，而产品是由编译器生成的二进制文件。

当然，将类图作为概念级别的粗略草图没有什么错，但是如果从它们生成代码有什么价值的话，我认为我们现在都应该这样做了。(我知道，上一次陈述不是为了证明，而是为了为索赔提供证据，不是吗？)

Answer 3

在瀑布为王的一些利基市场中，需要类图作为软件设计文档的一部分。

在这种情况下，从图表生成代码是有意义的。