利用面向对象程序设计促进进步的利弊

Question

我理解使用面向对象编程作为概念的优缺点。我正在寻找的是具体使用oo进行中/开放的利弊。我需要考虑哪些挑战？该语言的某些部分是否与oo不能很好地融合？类似的东西。

编辑：使用10.2b

Answer 1

我会告诉你我的意见，但要预先警告我可能是那里最大的进步仇恨者。 ;）那就是说，我已经在OOABL写了几个中型项目，所以我在该领域有一些经验。这些是我写的一些东西，所以你知道我不是在说我的话：

• 客户端和服务器的STOMP协议框架
• 一个简单的ORM模仿ActiveRecord
• 我所在组织的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也不起作用， 如果记忆服务。
• 根据您的环境，代码审查可能很难 进度开发人员不做OOABL，因此可能无法理解您的代码
• 如果上述观点属实，您可能会面临积极抵抗 根深蒂固的开发人员，他们不得不学习新的东西 事

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

现在，理论上可能尝试使用MEMPTR，固定数组（EXTENT）和WORK-TABLE来构建其中的一些东西。但是，我在10.1C尝试了这个，由于缺少接口继承和抽象类，设计崩溃了，正如我所料，性能非常糟糕。后一部分可能仅仅是由于我的能力差，但我怀疑这是一个几乎不可能克服的实施限制。

如果绝对必须在OpenEdge中进行编码，则底线是使用OOABL - 它比程序性ABL更好，并且在每次迭代发布OpenEdge后粗糙边缘变得稍微平滑。但是，它永远不会是一种美丽的语言（OO或其他）。

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

Answer 2

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

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

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

一些OO功能缺失或不好：

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

因此，如果您熟悉其他语言的oo编程并开始使用OOABL，那么您可能会遇到许多您希望存在的事情，并且在尝试实现此类事情时会感到沮丧ABL。

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

Answer 3

K +

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