您可以用任何语言编写错误的代码。 因此，" OOPs彻底削弱技术"的说法是无效的。

或者您可能正在努力理解合理的OK代码。 但是，如果不告诉我们什么是无法理解的，或者为什么应该如此，我们就无法真正提供任何信息。

如果您想要无法理解的代码，请尝试Malbogle 。 我不同意您关于ABAP属于同一类别的主张。 我可以理解大多数ABAP代码。 实际上，我发现好的OO ABAP比遗留代码容易理解。 OO是一个成熟的概念，已经存在了很长的时间-确切地说是从1960年代开始。 我认为，如果无法理解，它还会存在。

我不会四处走走。简单的示例显示主程序仅显示多个包含。

所以乍看之下看不到代码是什么目的。

每个include都在处理整个程序功能的哪一部分，除非开发人员文档不清楚。

假设您正在寻找一种功能，以查找在ME23N中显示交货计划日期的逻辑背后的原因。

您查看程序，屏幕。当您检查pai字段的模块之一时，它进一步为您提供了一个include，然后一个include将具有一个类，该类具有9种方法来获取交货计划数据。

当您转到所需的位置时，将出现一个增强点。此外，该增强点还将包含另一个。

增强点也将具有标准实现。

再次包含将具有一个功能模块，并且该功能模块将分支到一个新的 class.By 遍历如此之大的时间，您甚至会忘记从哪里开始，您的目标是什么？现在想一想，如果没有调试器，人们将如何理解。没有很长一段时间的调试器，当采用过程性方法时，开发人员仍然设法 了解并做出贡献。

您设计UML，设计模式，然后将所有这些移交给一个全新的人。看看他的理解和判断。

如果树液实验室的人们只理解这样的代码，而其他人却不理解，那么仍然有待解决。最后但并非最不重要的是，也不知道badi实现方法的执行顺序。

我感觉到您的痛苦，阿迪亚！ 也许我的博客文章" 从头开始，我很难把头围在ABAP-OO 上，尤其是它所产生的许多有用的评论和讨论都会有所帮助。 我仍然没有"那里"，但我至少有时尝试使用ABAP-OO。

确切地说，我的意思是从开发人员的角度来看抽象原理会窃取他的知识。

他只需调用method即可完成工作。

但是核心API的复杂性由制作该API的其他不同开发人员处理。

开发人员本人对此一无所知。

我用OOPS范式实现的其他问题虽然并不完全反对。但是它必须位于中心域中，示例汇编语言主要用于基于OS的处理，类似地，OOPS的目的也必须 只限于设计早期的原型或RAD工具。

使用OOPS的开发人员也无法完全控制自己的编码。

示例：我需要使用set_alv_for_first_display显示alv报告。 我主要要做的是提供必要的参数来调用此FM，并提供一些必填项和一些我喜欢的属性，以带来一些自定义效果。 但是我的控制仅限于此FM上提供的接口。 我不知道在每个显示的单元格中如何进行洪水填充，或者我可以在alv中使某些东西开始闪烁。.您做的许多事情和您都知道通过调用方法来完成。 但是，复杂性处理方式的这一抽象层从未使开发人员感到最佳。

我们只使用REUSE_ALV_HIERSEQ_LIST_DISPLAY，对此感到高兴。

但是该树节点如何变成图片，其背后是什么图形，涉及链表或队列的逻辑完全不在我们的范围之内。