似乎我们的大多数SAP程序员都在使用旧版本的ABAP，这是面向对象的东西。我还注意到，OO语言更清晰，更现代（他们显然借此机会摆脱了被弃用的东西）。
由于系统还没有推出，现在是时候进行重新设计了，而不是以后。
值得请求将新代码编写为OO ABAP程序？如何将其出售给管理层？与非OO程序的接口是否运行良好？
（更新后请注意，我正在专门讨论新代码，尤其是计划在明年进行的代码）
答案 0 :(得分：6)
如果它正在生产中，请不要重写代码。不值得花时间或金钱，没有管理层（在一家足以运营SAP的公司）会同意它。
除非你转移到绿色的田野环境，否则你永远不会在OO中重写所有内容。 SAP甚至没有使用其核心ECC模块。期望能够用你的自定义东西来做这件事是不现实的。
我会读到OO ABAP并开始用它编写新程序。
OO ABAP和程序ABAP合作得很好。你可以打电话给班级＆amp;来自程序性程序的方法和（更有限，但反之亦然）。
答案 1 :(得分：4)
我们为客户开发了许多新的，新的ABAP代码，ABAP OO的使用正在缓慢增长，但仍在增长。
说服新开发人员使用ABAP OO更容易，因为要学习的内容要少得多。此外，使用OO ABAP编写代码可以正确使用设计模式，高效的单元测试，UI抽象（例如SAPgui和WebDynpro或SAP控制台），并且可以大量减少文档。
此外，正如一些人之前所说，SAP并未将其代码库重写为ABAP OO。但他们肯定试过改写ME51的ME51N，ME21的ME21N和SO01的SBWP。
此外，来自SAP的所有新API，如ABAP单元，ABAP代理，新ALV，用于ABAP的WebDynpro以及全新的增强和交换框架都是很好的例子（我认为），为什么你应该注意一下它
答案 2 :(得分：2)
这取决于要编写的程序的大小。如果它是一个没有太多数据库交互的大型“系统”，那么可能会有一些好处。对于较小的程序，我没有看到“客观化”代码的任何优点。
这还取决于开发人员的技能和偏好。如果他们想要“OO”，可能会有更好的环境。如果他们陷入“旧的程序化”思维方式，那么可能有其他方法来改进代码而不是切换到OO。
我常见的一个例子是讨论“数据库应该做什么”（例如连接，排序，分组）与“我应该在代码中做什么”。
答案 3 :(得分：2)
我刚刚在SAP SDN上找到了Esti白皮书的副本：Not Yet Using ABAP Objects? Eight Reasons Why Every ABAP Developer Should Give It a Second Look
本文简要介绍了使用ABAP OO的好处。
答案 4 :(得分：1)
尝试查找白皮书的副本：
尚未使用ABAP对象？ Horst Keller和Gerd Kluger 的每个ABAP开发人员应该重新审视的八个理由。
SAP OO的一些最大优势，特别是对于新的SAP开发人员而言，它会迫使您更加明确程序化ABAP。它使编写的代码更易于维护，并且对于来自更主流背景的程序员来说可能会更熟悉。
答案 5 :(得分：1)
旧的经典报告通常包含冗余编码。不同的报告已经建立了很多“复制和粘贴”。尝试找出哪些内容是多余的，然后将它们 - 逐步 - 从这些报告中提取到新的全局，可重用，设计良好的类中，并通过将“调用方法”替换为中央定义的现有代码来使旧报告更加严格经过充分测试的OO逻辑。