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

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

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

ME23N正在购买，这是被黑客砍死的SAP最古老的部分之一。 不管使用哪种编码范例都一定很复杂。 我挑战您提出一个基于过程的概念，该概念保留与20多年历史的功能（包括成千上万的用户出口实现）的兼容性，并且仍然为全球所有SAP客户提供所有新功能和增强功能。

两种可能性：

1。 您正在查看的特定代码很好，但是您缺乏理解它的技能

2。 您正在查看的特定代码不正确。

SAP开发的大量ABAP代码为OO。 您是否真的认为如果不值得，他们会这样做吗？ 您是否真的认为，如果OO存在根本性问题，那么Java将被广泛使用吗？

您的陈述的逻辑类似于"我看了一个苹果，发现它变质了，因此苹果是 有毒的水果，应避免食用。"

马修·比林汉姆

您好，马特-是的，要说出Aditya到底在说什么有点棘手。 某些原因可能是因为英语不是他的母语，这使清晰表达这些技术知识成为一个挑战。

我和我的团队多年以来一直与OO-ABAP合作， 并且在理解彼此的代码方面确实没有问题。 以下是一些可能会提高面向对象代码的可读性的因素：

• 约定和/或配置的标准化
• 使用设计模式
• 用于接口和抽象类的列表在哪里可以提供帮助
• SE24有一个不错的工具来概述给定类，接口等的UML图。
• 在团队中拥有经验丰富的架构师来设计类结构，然后再进行编码
  

不过我感到你很痛苦。 我已经看到一些经验不足的开发人员伪装为OO-ABAP进行函数式编程，这些可能很难理解。 要么; 缺乏设计模式经验或对体系结构原理的了解会导致不必要的复杂代码结构。

像任何工具一样； OO ABAP在经验丰富的手中很有用，在经验不足的手中也可能有害。

我也在此复制了

您知道会发生什么详细情况吗当您在汽车中转动方向盘时？

否，您知道给定一个输入（将方向盘向左转动）时，您会得到一定的输出（汽车的车轮向左转动）。< br>

嗨，

我个人遇到过OOPS ABAP的一些好处。

1。 使用测试双重框架的测试自动化：现在，由于我们能够使用单元测试类实现自动化测试，因此我们正在提供更强大的代码。 使用OOP概念，单元测试类更加有效。 尽管我们也可以将其用于经典ABAP，但是覆盖范围将大大减少。

2。 在实现模式方面，OOPS非常方便。 Singleton和工厂模式广泛用于前端开发。

3。 如今，由于OOPS具有多态，继承和抽象等特性，因此许多框架现在都在OOPS中开发。 您可以在BADI框架和ODATA框架中找到接口的使用。

我在经典ABAP中看不到很多优点。

谢谢

乔拉哈里（Ila Chaudhary）

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

您知道详细信息吗？
否，您知道给定输入（将方向盘向左旋转）时，会得到一定的输出（汽车的车轮向左旋转）。