我们可以将EiffelBuild用于大型项目，还是应该限制其用于原型设计？

Question

EiffelBuild是专为Eiffel设计的ISE GUI构建图形工具。

我尝试了，我发现它非常人性化，但我有点担心在大型项目中使用这样的工具。使用GUI构建工具可能具有限制性。

因为Eiffel继承使得创建组件变得非常容易，所以从长远来看，使用我们自己的专用版本的图形对象来使用标准对象可能会更好。

您是否了解EiffelBuild的任何限制，以避免其用于大型项目。

Answer 1

我会限制EiffelBuild用于原型设计。这是一个很好的工具，但从长远来看，管理EiffelBuild项目会变得越来越复杂（对大多数设计师来说也是如此）：

• 每隔6个月就会发布一个新版本的estudio，这使得必须让您的EiffelBuild项目仍然按照预期从一个版本运行到另一个版本是一个负担，期望每隔一段时间就必须处理迁移。现在你所有的Eiffel代码都会受到同样的挑战，但是对于EiffelBuild中的项目，你将不得不处理语言和EiffelBuild的变化（有时两者同时......）
• 如果版本N + 1和N不兼容，您必须创建EiffelBuild项目的分支以支持这两个版本，仅限于过渡期间
• 整合多个EiffelBuild项目可能很困难
• 某些图形组件可能难以在EiffelBuild中重用，例如专门的图表组件（即类集......），特别是如果该组件本身不是EiffelBuild项目
• 我发现将一个EiffelBuild应用程序制作的部件重用到另一个应用程序很困难，而使用设计得相当好的部件则很难解决问题

希望这有帮助。

Answer 2

  

我尝试了，我发现它非常人性化，但我有点担心在大型项目中使用这样的工具。使用GUI构建工具可能具有限制性。

这是如何“限制性”的？项目的规模如何发挥作用？

如果你的意思是它是一个代码生成器，并且你不完全理解它的代码，那么我完全同意。代码生成仅适用于您手动冷却编写代码的情况，并且生成器通过保存繁重的工作为您提供电梯。在这种情况下，您完全有信心修改和维护生成的代码。

  

因为Eiffel继承使得创建组件变得非常容易，所以从长远来看，使用我们自己的专用版本的图形对象来使用标准对象可能会更好。

您要添加的专业是什么？我会仔细考虑这样做，因为它意味着在perpetuam中编写，调试和维护一个大的类层次结构。绝对肯定专业化是必要的，值得付出代价，并且在采取这一步骤之前无法通过任何其他方式获得。在你决定之前，要诚实地量化成本。

一旦使用库GUI类完成了足够的手动编码，我就会投票支持编写自己的代码生成器。这是一个可持续的解决方案，IMO。

更新：

我在一个研究生课程中学习了埃菲尔，该课程在90年代中期决定它是最好的面向对象语言。当时，C ++是卓越的，但被认为是复杂的，Java并没有从Sun的实验室中脱颖而出，而C＃甚至不是安德斯眼中的闪光点。这个机构的教师迷恋于合同设计和它隐含的学术严谨性。

我读过迈耶斯的“面向对象软件构建”。第一版介绍了DbC，并使Meyers在面向对象的世界中成为明星。在我看来，第二版是一个臃肿的东西，结束了他的上升。

老实说，如果你是为雇主写这个庞大的系统，我建议你放弃艾菲尔，为了他们和你的利益而转向更主流的语言。如果你在Windows平台上，C＃可能是一个不错的选择。如果您有异构环境或无法负担Microsoft堆栈，请使用Java。

所有关于埃菲尔的四个标记问题。我认为音量说了些什么。你可能是对的，人气并不总是质量的最佳指标。我被告知Beta是比VHS更好的技术解决方案，但事实是它在市场上输了，今天无处可寻。与埃菲尔相同。如果我是你，我会放弃它。

更新2：

非常好 - 我无法从您的原始帖子中了解您使用其他语言的体验。

“对质量的高期望”意味着您相信Eiffel将以您无法与其他语言复制的方式支持语言级别的质量。我不同意这一点。代码的质量更多地与开发人员的技能和实践相关，而不是语言本身。

按合同设计完全超卖，IMO。我已经读过它在生产中经常被关闭，因为它确实代表了性能损失。如果这对你来说是真实的，你还期望埃菲尔对质量做出贡献吗？

我确保你正在编写这个应用程序的客户理解与Eiffel一起做出决定的全部后果：有限的开发人员维护它，一个因使用死语而被边缘化的员工等等。由于主观愿望，请确保不要过度使用。