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

Question

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

编辑:使用10.2b

Answer 1

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

• 客户端和服务器的STOMP协议框架
• 一个简单的ORM模仿ActiveRecord
• 我所在的组织的ABL编译器接口(后端和前端)
• 用于构建Excel和Word文档的库(使用MS Office 2003 XML模式序列化它们;没有那些愚蠢的COM内容)
• 可以使用多种策略发送电子邮件的电子邮件客户端

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.

Answer 2

在过去的四年里,我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 bridge从现有的进度代码中调用它,这非常顺利.