使用面向对象编程的优点和缺点答案

【问题标题】：Pros and Cons of using object oriented programming for progress openedge使用面向对象编程的优点和缺点
【发布时间】：2012-05-04 10:51:55
【问题描述】：

我了解使用面向对象编程作为概念的利弊。我正在寻找的是专门使用 oo in progress/openedge 的优缺点。我需要考虑哪些挑战？语言中是否存在与 oo 不匹配的部分？像那样的东西。

编辑：使用 10.2b

【问题讨论】：

您使用的是哪个版本的 Progress/OpenEdge？
如果您使用 OOP，一个明显的缺点是当您尝试使用 ProxyGen 为您的类生成 .NET 代理时。代理生成器不允许 CLS 作为输入，您必须编写网关过程来公开它们。 KB Article

标签： oop progress-4gl openedge

【解决方案1】：

我会给你我的意见，但请注意，我可能是最讨厌进步的人。 ;) 也就是说，我已经在 OOABL 中编写了几个中型项目，因此我在该领域有一些经验。这些是我写的一些东西，只是为了让你知道我不是在说我的帽子：

客户端和服务器的 STOMP 协议框架
一个模仿ActiveRecord的简单ORM
我所在的组织（后端和前端）的 ABL 编译器接口
用于构建 Excel 和 Word 文档的库（使用 MS Office 2003 XML 模式对其进行序列化；没有那些愚蠢的 COM 东西）
可以使用多个strategies 发送电子邮件的电子邮件客户端

OOABL 专业人士：

如果您绝对必须编写 Progress 代码，那么它是创建可重用代码的绝佳选择。
清理现有程序代码库的好方法

OOABL 缺点：

类层次结构是有限的；你不能创建继承的（子） 10.2B 中的接口（我认为这将在 11 中添加）。年长者 OpenEdge 的版本还有其他限制，例如缺乏抽象类。这会限制您创建干净的 OO 设计的能力，并且将当你开始构建不平凡的东西时会伤害你。
错误处理很糟糕 - CATCH/THROW 不允许你抛出你的自定义错误并强制调用者捕捉它们。向后兼容性阻止这种情况进一步发展，所以我怀疑它会不会有所改善。
对象内存占用大，没有AVM调试追查原因的工具（一定要喜欢这些封闭的系统！）
直到 10.2A，垃圾回收才存在，现在仍然存在即使在 11 中也有一些错误（有关示例，请参见官方 OE 论坛）
网络编程（使用套接字）是一个 PITA - 你必须运行一个单独的持久过程来管理套接字。我认为发生了 OOABL 中的编程通常是一个 PITA；我记得得到了很多关于“窗口环境”或类似情况的错误尝试使用它们时。 PUBLISH/SUBSCRIBE 也不起作用，如果没记错的话。
根据您的环境，代码审查可能很困难，因为大多数 Progress 开发人员不做 OOABL，因此可能无法理解您的代码
如果上述观点成立，您可能会面临来自根深蒂固的开发人员，他们因必须学习新知识而感到威胁事情

OO 就是构建小的、可重复使用的部分，这些部分可以组合成一个更大的整体。 OOABL 的一个大问题是“ABL”部分因其粗糙的数据结构和缺乏枚举器而拖累你，这使你无法真正用它构建真正漂亮的东西。不幸的是，由于它是一种封闭的语言，你不能只是回避你的手，并在外部为它创建自己的新数据或控制结构。

现在，理论上有可能尝试使用 MEMPTR、固定数组 (EXTENT) 和 WORK-TABLE 构建其中的一些东西。然而，我曾在 10.1C 中尝试过，但由于缺少接口继承和抽象类，设计失败了，而且正如我所料，性能相当糟糕。后半部分可能只是因为我的能力差，但我怀疑这是一个几乎无法克服的实现限制。

如果您绝对必须在 OpenEdge 中编码，最重要的是使用 OOABL - 它比程序 ABL 更好，并且在 OpenEdge 的每次迭代发布后，粗糙的边缘会稍微平滑一些。但是，它永远不会是一门漂亮的语言（OO 或其他）。

如果您想学习正确的面向对象编程并且不局限于 ABL，我强烈建议您研究一种将对象视为一等公民的语言，例如 Ruby 或 Smalltalk。

【讨论】：

谢谢，这真的很有帮助！
你不能比我更讨厌opengge！恕我直言，Progress 应该放弃 ABL 并致力于杀手级 SQL 和无 SQL 实现，没有人想要 ABL
至少对我来说最糟糕的部分是缺少允许 map/queue/deck/list 实现的一流数组。

【解决方案2】：

K+

只有一件事——“错误处理很糟糕”——这很糟糕，但不是因为你不能让你自己的错误类在调用者块中捕获它们——这行得通，我正在使用它。糟糕的是旧的 NO-ERROR / ERROR-HANDLE 选项和 Progress.Lang.Error / CATCH 块和 ROUTINE-LEVEL ON ERROR UNDO, THROW 的混合。这是一个大问题，当团队中没有约定时，将使用哪种错误处理以及如何使用。

【讨论】：

对。我试图保持简洁，但我的意思是在 Java 中（本质上是 OOABL 尽其所能复制的内容），当我定义一个 THROWs 一些错误的方法时，其他人调用我的方法，他们必须CATCH我将抛出的潜在错误（或者重新THROW它再次调用堆栈）。在 ABL 中，没有编译时强制执行此操作。在 OOABL 中编写自定义错误类基本上只为您提供自定义错误编号和消息。即使使用ROUTINE-LEVEL ON ERROR UNDO, THROW，您也无法获得像 Java 这样好的控制流。
或者，更简单地说，调用者可能永远不会知道您的方法抛出了自定义异常（例如FileNotFoundException）。调用引发自定义异常的方法时根本没有编译器消息。他们将不得不查看您的源代码并查看您的方法是否引发错误。在 Java 中，编译器会强制您捕获或重新抛出，即使您打算忽略它。
@AbeVoelker 您所指的是“检查异常”的名称，它被随便列为各种“Java 宠儿”列表中的顶级项目之一。臭名昭著的 Anders Hejlsberg 提出了为什么受检异常弊大于利的最佳解释之一可能是：artima.com/intv/handcuffs.html 除此之外，我完全同意您对 ABL 的批判性分析，包括您在这里和博客上的许多其他帖子。我不会认为你是一个“仇恨者”，而是一个关心他的工具集的专业人士。
@VladGudim 感谢这篇有趣的文章！我现在可以看到类型异常如何导致紧密耦合的代码。说实话，我只在学校学过 Java，所以从来不用针对大型代码库编写 Java 代码，也不必编写其他人必须使用的库。所以我可能不应该就这个问题发表宗教观点。另外，谢谢你的客气话。在完成我一直在研究的 DataMapper 数据库适配器之后，我应该在一个月或更短的时间内发布一篇新的博客文章（不幸的是，我不得不谈论失败的 0MQ 绑定）。和平！

【解决方案3】：

在过去四年中，我 80% 的时间都在使用 OOABL（从 10.1c 开始）。我绝对推荐使用OOABL，但我认为考虑使用OOABL 与其他OO 语言相同的方式充满问题是非常重要的。 “相同方式”是指在 oo 世界中常见的设计模式和实现实践。此外，某些类型的应用程序，尤其是在技术框架领域的应用程序很难使用 OpenEdge（例如 ORM）。

原因是 OOABL 的性能问题和语言中缺少 OO 功能。

例如，如果您使用 C# 或 Java 进行编程，那么在许多情况下，对象的内存占用和实例化时间并不是一个大问题。使用 ABL 这经常成为一个大问题。这会导致其他设计决策并阻止某些模式和框架的实现。

一些缺失或不好的 OO 特性：

没有类库，oo 不需要数据结构
在 java 中没有包可见性（在 c# 中是内部的）这在大型应用中尤为重要
没有泛型
非常糟糕的异常处理
反射能力非常有限（在 oe11 中改进）

因此，如果您熟悉其他语言的 oo 编程并开始使用 OOABL，您可能会错过很多您希望在那里实现的东西，并且在尝试用其他语言实现这些东西时会感到沮丧ABL。

如果您的应用程序只能在 Windows 上运行，也可以在 C# 中实现新的 oo 代码，并通过 clr 桥从您现有的进度代码中调用它，这非常顺利。

【讨论】：

+1 表示一切。很高兴我不必再碰它了。如果我这样做了，我会使用 .NET，其他一些使用 SQL 适配器访问数据库的语言，或者编写 C 代码并且只编写 ABL 作为它的包装器:-)