代码之家  ›  专栏  ›  技术社区  ›  Wizard of Kneup

更改生成的代码还是使用继承?

  •  7
  • Wizard of Kneup  · 技术社区  · 16 年前

    我在一个EMF项目上工作。其中一个设计决策是不接触生成的代码,也不签入它。相反,每当需要更改某些内容时,都会创建包含这些更改的子类。框架足够灵活,可以处理这一问题。然而,我也经历过一些间接的工作。

    设计决策的基础是对其他代码生成框架的不良经验进行重新生成,让问题得以解决。

    作为项目的新手,我想挑战这个设计决策,但我想先听听大家的意见。我知道EMF项目团队建议对代码进行更改。但是你的经历是什么?EMF如何处理生成代码中的手动代码更改?你是否曾经到过失去手工编写代码的地步?代码是否曾进入不可维护状态?

    2 回复  |  直到 8 年前
        1
  •  7
  •   Stephen C    8 年前

    但是你的经历是什么?

    我已经实现了两个独立的项目,这两个项目都涉及50个或更多模型类的模型,并且在这两种情况下,模型在项目的整个生命周期中都在发展;也就是说。 太多了 模型更改。在这两种情况下,我将生成的代码修改为通常实现计算属性、验证和以各种方式自定义编辑器。

    EMF如何处理生成代码中的手动代码更改?

    它工作得很好。生成器偶尔会产生由于某些模型更改而无法编译的代码,但修复通常是简单的,例如删除Java类/接口、死导入等。

    你是否曾经到过失去手工编写代码的地步?

    只是偶尔。偶尔,您会忘记删除“生成的”标记注释,当您重新生成模型时,您的方法会遭到破坏。

    (我想,如果这是一个主要问题,您可以修改EMF生成器,以便在合并更改之前始终备份源树。)

    我想最让人恼火的是生成的代码必须被格式化。 不幸的是,Eclipse代码格式化程序非常糟糕,但是如果手动重新格式化, 下次重新生成时,您的格式更改会被删除。但这很刺激…不值得跳过铁圈来避免。

    代码是否曾进入不可维护状态?

    不。从来没有。


    阅读consta_a的答案会提醒我,我总是将生成的EMF类检查到版本控制中。这是避免长期丢失手写编辑的最佳方法。


    2018年更新:我所说的两个EMF项目发生在2008年之前。从那时起,电动势世界可能发生了变化。我一直没有跟踪。

        2
  •  0
  •   consta_a    14 年前

    我确认了Stephen C的答案:在我们的例子中,我们在模型中处理大约120个类,这意味着120个接口+120个实现类+无数的编辑类和重新生成非常顺利(如果我们能够轻松地使生成的类格式化为我们想要的格式(^ ^))。

    提示:如果担心丢失一些手工编写的代码,最好是将代码保存在存储库中。每次进行更改时,都可以轻松地与以前的版本进行比较,并查看更改内容。

    推荐文章