1

在我的公司从 4.6c 升级到 ECC6.0 几个月后，我们的程序员团队仍在使用传统的 4.7c 方式进行编码。我渴望尝试 ABAP 的新 OO 方法，但令我沮丧的是，这里的大多数人只强调在给定的最短时间框架内完成工作。

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

4

7 回答 7

10

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 中获利。有很多没有 OO 知识的有经验的 ABAP 开发人员被迫编写类。他们所做的实际上是用类模仿程序原则（例如，一个只具有静态方法的类——作为功能模块/子程序的替代品）。

祝您的组织好运，迎接 ABAP OO 的挑战！这与语言无关，更多的是让 OO 原则进入员工的脑海。

于 2009-03-11T20:59:07.157 回答
2

我不了解 ABAP，但我看到 VB 开发人员迁移到 .Net 平台时也发生了同样的情况。

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

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

但根据我的经验，很难用这样的合理论据说服人们走出他们的舒适区。给他们指路通常效果更好。慢慢开始在你自己的代码中使用 OO 结构，向人们展示它看起来多么干净。这不是您在几个月内就能实现的目标，可能需要数年时间才能让人们以不同的方式思考和工作。

于 2009-03-11T08:42:27.803 回答
2

一个由经验丰富的程序开发人员组成的团队不太可能很快开始以 OO 风格进行开发，除非付出大量（且昂贵）的努力来培训和指导他们。

原因有很多：

  • 在真正的 OO 环境（smalltalk，不是 java 或 c++）中投入大约一年的时间才能在 OO 开发方面取得任何优势。
  • 他们不能从头开始，有很多遗留代码和时间压力。
  • 他们所有的遗留代码都不是面向对象的。重组需要付出巨大的努力。
  • 遗留代码结构不完善，有很多重复，没有单元测试。改变它需要太多时间，所以他们没有时间修复。（令人惊讶的是，您可以在不了解项目的情况下从项目中推断出。:)）。

因此，他们的新代码很可能是程序性的，但在类和方法中。他们不会被 OO 的优势所折服。

于 2009-03-11T08:43:33.913 回答
2

切换到 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 开发人员都应该重新审视它的八个原因。霍斯特·凯勒和格德·克鲁格
于 2009-03-16T03:51:27.973 回答
2

OO 与否 OO 不是问题！！

问题是哪里 OO 哪里不是 OO 。

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

用户出口，事件：大部分数据在界面中提供。对客户特定数据或定制的访问可以放在对象中。

报告：大部分数据将通过标准 FM 读取。具体的数据处理可以放在对象中。可以在其他报告中轻松重复使用。SAP enjoy 控件可以用对象外壳包裹，以便于使用和重用。屏幕不能是对象中的位置。:-(((

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

于 2009-05-20T06:32:23.777 回答
1

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

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

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

因此，ABAP 对象通过程序 ABAP 为您提供了以下功能：

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

程序 ABAP 只有两个目的是必不可少的：

  • 经典画面在功能模块中的封装。
  • 当您想让函数对其他系统可用，但无法使用 XI 服务器代理使类方法在外部可用时。在这种情况下，您必须使用功能模块。

在这里详细研究它们，您会发现您不需要任何重要的操作/演示理由来说服自己迁移到 OO ABAP，因为所有这些理由已经非常重要。

于 2009-03-11T07:36:41.470 回答
1

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

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

于 2013-03-21T08:29:48.990 回答