OO ABAP：何时以及为何？

Question

在我的公司从4.6c升级到ECC6.0后的几个月，我们的程序员团队仍然以传统的4.7c方式编码。我很想尝试ABAP的新OO方法，但令我沮丧的是，大多数人只强调在最短的时间内完成工作。

我的问题是：
1）您组织中的人员何时开始在OO ABAP中开始编码？
2）人们是否想要以OO方式对其进行编码有什么重要原因？例如调用方法比PERFORM语句更快？

Answer 1

1）您组织中的人员何时开始在OO ABAP中开始编码？

我的组织中的大多数开发人员在引入ABAP OO之前已经学习了经典的ABAP。他们大多是高级开发人员，他们不会学习正确的OOP和OOD原则。他们仍然主要使用程序性ABAP功能。 此外，我们在传统环境中工作。我们后端的基础是在4.6C的时间内建立的。很难将适当的OO设计引入遗留系统。

另一方面，程序功能仍然有效。事务数据库更新等一些功能主要用于ABAP的过程部分。您可能只知道数据库事务的更新功能模块或子例程（可以调用IN UPDATE TASK的那些）。它们是ABAP基本组件的组成部分。人们不能否认仍然需要程序性的ABAP部分。

2）是否有任何重要原因让人们想要以OO方式对其进行编码？例如调用方法比PERFORM语句更快？

你是如何比较CALL METHOD与PERFOM的运行时间的？您是否尝试过程序RSHOWTIM /或者您是否已从ABAP工作台进行了一些性能测试？单个子例程调用与方法调用没有显着差异。但是，如果在质量测试方法中调用，则调用具有稍微好一点的性能（在微秒级）。

总的来说，我建议OOD和OOP使用与之前发布的用户相同的参数。但是你必须记住，熟悉旧ABAP世界的高级开发人员在开始编写ABAP OO之前必须先了解OO原则。 否则，您的组织将无法获得ABAP OO的利润，相反。有很多经验丰富的ABAP开发人员没有OO知识，他们被迫去编写课程。他们所做的实际上是用类来模仿程序原则（例如，一个只有静态方法的类 - 作为函数模块/子程序的替代）。

祝您ABAP OO挑战您的组织！它不是关于语言，而是关于将OO原则引入员工的想法。

Answer 2

我不知道ABAP，但我也看到VB开发人员迁移到.Net平台也是如此。

程序员对旧的编程方式很满意，旧的方式仍然有效。新的编程方式需要大量投资，不仅来自公司，还来自那些不得不走出自己的舒适区域到不确定领域的人们。如果你的公司不愿意投入培训和研究时间，这个问题会变得更大，因为人们将不得不投入自己的时间，而不是每个人都愿意这样做。

正如Taurean已经表明，有令人信服的理由转向OO的做事方式。它们主要不是关于性能，而是关于系统中组件的更好解耦，使其更易于维护。

但根据我的经验，很难用相应的理由说服人们走出他们的舒适区。它通常更好地向他们展示方式。慢慢开始在您自己的代码中使用OO构造，向人们展示它看起来多么干净。这不是几个月你会达到的，可能需要数年才能让人们以不同的方式思考和工作。

Answer 3

一个经验丰富的程序开发人员团队不太可能很快开始以OO风格开发，除非为培训和指导他们做出了重大（且代价高昂）的努力。

有很多原因：

• 在真实的OO环境（smalltalk，而不是java或c ++）中沉浸大约需要一年才能在OO开发中获得任何好处。
• 他们无法从头开始，有很多遗留代码和时间压力。
• 他们所有的遗留代码都不是OO。重组需要付出很大的努力。
• 遗留代码结构不合理，并且有很多重复，没有单元测试。改变它需要花费太多时间，所以他们没有时间来解决问题。 （令人惊讶的是，你可以从项目中推断出什么，而不了解它。:)）。

因此，他们的新代码很可能是程序性的，但在类和方法中。他们不会对OO的优势印象深刻。

Answer 4

切换到ABAP OO的一些好理由是：

• ABAP OO更明确，更易于使用
• ABAP OO进行了更严格的语法检查，消除了ABAP语言中的许多含糊之处
• 许多新的Netweaver功能仅可使用OO

将此添加到Taurean列出的权益中：

• 更好的数据封装
• 多个实例
• 更好的垃圾收集
• 通过继承重用代码
• 通过标准接口处理业务对象
• 事件驱动编程

开始使用ABAP OO：

• 首先在代码中调用一些SAP标准OO功能：使用ALV类而不是函数模块 - 这些类提供了更多功能。尝试调用CL_ABAP*或CL_GUI_FRONTEND*类
中的一些标准方法
• 使用本地类
将报告编写为Singleton
• 尝试在SE24中设计一个简单的类，用于您熟悉的事物（例如文件处理程序）

资源：

1. Igor Barbaric的面向对象ABAP中的设计模式
2. 尚未使用ABAP对象？每个ABAP开发人员应该重新审视的八个原因。作者：Horst Keller和Gerd Kluger

Answer 5

是否OO不是一个问题！

问题在于OO和不在哪里。

只要您处于客户名称空间，就可以充分利用OO方法（OOD和OOP）的所有优势。但是，每次访问SAP标准功能都会产生巨大的麻烦。 事务完整性，对象一致性和同步，数据库提交，屏幕（模块池和选择屏幕），权限检查，批量输入。这些只是在OO方法中难以（甚至不可能）集成的一些对象。 SAP标准模块的集成使其更加复杂。

用户退出，事件： 大多数数据都是在界面中提供的。可以将对客户特定数据或自定义的访问放在对象中。

报告：大多数数据将由标准FM读取。特定数据处理可以放在对象中。可以在其他报告中轻松重用。 SAP享受控件可以用对象shell包装，以便于使用和重用。屏幕不能在物体中。 ： - （（（

核心处理：SAP不鼓励更换SAP业务对象维护或SAP流程。但如果这是患者的病例并准备好付出巨大努力。让我们看得更近。有许多技术挑战：单例模式，数据库访问优化，锁定，同步等。应该解决技术和业务功能的分离问题。 Objets不适合大规模处理（高DB负载），因此应该进行大规模处理。

Answer 6

以下是您必须知道的OOP的一些优点：

• 数据封装
• 实例化
• 代码重用
• 接口

利用这些，尽可能“使用OO ABAP”有许多重要原因。即使您不想使用OO编程，使用ABAP对象仍然是一个好主意，因为它提供了程序编程所没有的一些功能。

所以这是ABAP Objects为您提供的程序ABAP：

• 更好的封装
• 支持多实例化
• 更好的重用代码技术
• 更好的界面
• 明确的事件概念

程序性ABAP只有两个目的：

• 经典屏幕的封装 功能模块。
• 当您想要制作功能时 可用于其他系统，但是 无法制作类方法 使用XI服务器在外部使用 代理。在这种情况下，你必须 使用功能模块。

详细研究它们here，您将看到您不需要任何重要的操作/示范理由来说服自己转向OO ABAP，因为所有这些原因已经非常重要。

Answer 7

简单来说，当你有一个相对年轻的团队渴望并准备好学习新的编程范例时，请使用它。在一个资深主导的团队中，收养OO可能具有挑战性。更是如此，因为该程序的可维护性下降。组织可能需要新员工来维护OO代码。

从设计的角度来看，毫无疑问（正如很多人在这个论坛上所说的那样）它是最好的，并且自古以来就一直在使用。 SAP在技术方面落后了。他们的ECC DB设计仍然是2-NF。标准的3-NF就是他们所谓的'3D'数据库。 没有偏离主题太多，我相信你现在有太多好的答案来做出决定。