3

EiffelBuild 是专用于 Eiffel 的 ISE GUI 构建图形工具。

我试了一下，发现它非常用户友好，但我有点担心在大型项目中使用这样的工具。GUI 构建工具的使用可能会受到限制。

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

您是否知道 EiffelBuild 的任何限制可以证明避免将其用于大型项目。

4

2 回答 2

3

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

  • 新版本的 estudio 每 6 个月发布一次，这使得必须让您的 EiffelBuild 项目在一个版本到另一个版本之间仍然按预期工作是一种负担，预计必须每隔一段时间处理一次迁移。现在，您的所有 Eiffel 代码都将面临同样的挑战，但是对于 EiffelBuild 中的项目，您将不得不处理语言和 EiffelBuild 的更改（有时同时处理两者......）
  • 如果版本 N+1 和 N 不兼容，则必须创建 EiffelBuild 项目的分支以支持这两个版本，仅在过渡期间
  • 集成多个 EiffelBuild 项目可能很困难
  • 某些图形组件可能难以在 EiffelBuild 中重用，例如专门的图表组件（即一组类...），尤其是如果该组件本身不是 EiffelBuild 项目
  • 我发现很难将由一个 EiffelBuild 应用程序制成的部件重用到另一个应用程序中，而对于设计得相当好的组件，它的问题要小得多

希望这可以帮助。

于 2009-09-19T05:59:06.253 回答
1

我试了一下，发现它非常用户友好，但我有点担心在大型项目中使用这样的工具。GUI 构建工具的使用可能会受到限制。

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

如果您的意思是它是一个代码生成器，并且您不完全理解从中产生的代码，那么我完全同意。代码生成仅适用于您手动编写代码的情况，并且生成器通过节省繁重的工作来帮助您。在这种情况下，您对修改和维护生成的代码充满信心。

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

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

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

更新：

我在一个研究生课程中学习了 Eiffel，该课程在 90 年代中期决定它是最好的面向对象语言。当时，C++ 是卓越的，但被认为是复杂的，Java 还没有从 Sun 的实验室中脱颖而出，C# 甚至在 Anders 的眼中都没有闪烁。该机构的教职员工迷恋于合同设计和它所暗示的学术严谨性。

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

老实说，如果您正在为雇主编写这个大型系统，我建议您放弃 Eiffel，并为了他们和您的利益而改用更主流的语言。如果您在 Windows 平台上，C# 可能是一个不错的选择；如果您有一个异构环境或买不起微软堆栈，请使用 Java。

SO 有关于 Eiffel 的所有四个标记问题。我认为音量说明了什么。您可能是对的，流行并不总是质量的最佳指标。有人告诉我，Beta 是比 VHS 更好的技术解决方案，但事实是它在市场上失传了，今天无处可寻。埃菲尔也一样。如果我是你，我会放弃它。

更新 2：

非常好 - 我无法从您的原始帖子中看出您对其他语言的体验。

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

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

我会确保您正在为其编写此应用程序的客户了解使用 Eiffel 的决定将带来的全部后果：有限的开发人员来维护它，员工因使用死语言而被边缘化，等等。确保您不会因为主观愿望而过度销售它。

于 2009-09-12T16:32:56.480 回答