OO ABAP:何时以及为何？

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

我的问题是:
1)您组织中的人员何时开始在OO ABAP中开始编码？
2)有没有重要的理由让人们想要以OO方式对其进行编码？例如,Call Method比PERFORM语句更快？

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

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

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

2)有没有重要的理由让人们想要以OO方式对其进行编码？例如,Call Method比PERFORM语句更快？

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

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

祝您的组织顺利应对ABAP OO!它不是关于语言,而是关于将OO原则融入员工的心中.