1) When do people in your organization actually started coding in OO ABAP?
Most developers in my organisation have learnt the classic ABAP before introduction of ABAP OO. They are mostly senior developers who restrain from learning proper OOP and OOD principles. They are still using mostly procedural ABAP features. Furthermore, we work in a legacy environment. the basics of our backend was build during the times of 4.6C. It is hard to bring proper OO Design into legacy systems.
On the other hand, the procedural features still work. Some features like transactional database updates are mostly used from the procedural part of ABAP. You might know Update Function Modules or Subroutines exclusively for database transactions (those you can call IN UPDATE TASK). They are an integral part of the ABAP basic components. One can't deny that the procedural ABAP part is still needed.
2) Is there any significant reason that people would want to code it in an OO way? e.g. Call Method is faster than a PERFORM statement?
How did you compare the runtime of CALL METHOD vs. PERFOM? Did you try the program RSHOWTIM / Or have you done some performance tests from the ABAP workbench? A single subroutine call does not differ significantly from a method invocation. However, if called in mass test method invocations have a slightly better performance (in the magnitude of microseconds).
On the whole, I recommend OOD and OOP with the same arguments as the users who posted before. But you have to keep in mind that senior developers familiar with the old ABAP world have to understand OO principles before they start writing ABAP OO. Otherwise, your organization would not profit by ABAP OO, on the contrary. There are a lot of experienced ABAP developers without OO knowledge who were pushed to write classes. What they do is actually mimicking procedural principles with classes (e.g. a class with static methods exclusively - as a substitute for function modules/subroutines).
Best of luck for your organisation for your challenge with ABAP OO! It is not about the language, it is more about getting OO principles into the mind of your staff.
I don't know about ABAP, but I have seen the same happen with VB developers moving to the .Net platform.
Programmers are comfortable in their old way of programming, and the old way still works. The new way of programming takes a lot of investment, not only from the company but also from people who have to move out of their comfort zone into uncertain territory. If your company is unwilling to invest in training and time for research this problem will get bigger because people will have to invest their own time, not everyone is willing to do that.
As Taurean already showed there are convincing reasons to move to the OO way of doing things. They're mostly not about performance but about better decoupling of components in your system making it far more maintainable.
But in my experience its hard to convince people to move out of their comfort zone using reasonable arguments like that. It usually works better to show them the way. Slowly start using OO constructs in your own code, show people how clean it looks. This isn't something you'll achieve in months, it can take years to get people to think and work differently.
A team of experienced procedural developers is unlikely to start developing in an OO style anytime soon, unless a significant (and expensive) effort is made to train and coach them.
There are numerous reasons for that:
It takes about a year of immersion in a real OO environment (smalltalk, not java or c++) to get any good at OO development.
They cannot start from scratch, there is a lot of legacy code, and time pressure.
All their legacy code is not OO. It takes a significant effort to restructure.
The legacy code is not well structured and has lots of duplication and no unit tests. Changing it takes too much time, so they don't have time to fix things. (It's amazing what you can deduce from a project without knowing anything about it. :) ).
As a consequence, their new code will most likely be procedural but in classes and methods. They will not be impressed by the advantages of OO.
Manipulate busines objects through standard interfaces
Event Driven programming
Starting to use ABAP OO:
Start by calling some SAP standard OO functionality in your code: Use ALV classes, rather than the Function Modules - the classes provides much more functionality. Try calling some of the standard methods in the CL_ABAP* or CL_GUI_FRONTEND* classes
Write a report as a Singleton using local classes
Try designing a simple class in SE24 for something that is familiar to you (a file-handler for instance)
Resources:
Design Patterns in Object-Oriented ABAP by Igor Barbaric
Not yet using ABAP Objects? Eight Reasons why Every ABAP developer should give it a second look. by Horst Keller and Gerd Kluger
只要您处于客户名称空间中，就可以充分利用 OO 方法（OOD 和 OOP）的所有优点。 然而，每次访问 SAP 标准功能都会带来巨大的麻烦。 事务完整性、对象一致性和同步、数据库提交、屏幕（模块池和选择屏幕）、权限检查、批量输入。 这些只是一些很难（甚至不可能）集成到 OO 方法中的对象。 SAP 标准模块的集成使这一问题变得更加复杂。
用户退出、事件： 大多数数据都是在界面中提供的。 对客户特定数据或定制的访问可以放置在对象中。
报告：大部分数据将通过标准 FM 读取。 具体的数据处理可以放在对象中。 可以轻松地在其他报告中重复使用。 SAP Enjoy 控件可以用对象外壳封装，以便于使用和重用。 屏幕不能放置在物体中。 :-(((
核心处理：SAP 不鼓励更换 SAP 业务对象维护或 SAP 流程。但如果这是一个耐心的情况，并准备好付出巨大的努力。让我们仔细看看。有很多技术挑战：单例模式、数据库访问优化、锁定、同步等。应解决技术和业务功能的分离问题。对象并不真正适合大规模处理（高数据库负载），因此应解决大规模处理问题。
OO or not OO is not a question!!
Question is where OO and where NOT OO .
All advantages of OO approach (OOD and OOP) can be fully exploited as long as you are in customer name space. However every access to SAP standard functionality creates huge headaches. Transactional integrity, object consistency and synchronisation, DB commits, screens (module pools and selection screens), authority checks, batch-input. These are just some of objects that is difficult (or even impossible) to integrate in OO approach. Integration of SAP standard modules moves this to even higher level of complexity.
User-exits, Events: Most of data are provides in interface. Access to customer specific data or customisation can be placed in objects.
Reports: Most of data will be read by standard FM. Specific data processing can be placed in objects. Can be easy reused in others reports. SAP enjoy controls can be wrapped with object shell for easy using und reusing. Screens can NOT be palces in objects. :-(((
Core processing: Replacing of SAP business object maintenance or SAP processes is not encouraged by SAP. But if this is a case by patient and ready for huge effort. Lets look closer. There are a lot of technichal challanges: singleton pattern, optimisation of DB access, locking, synchronisation, etc. Separation of technical and business functionality should be adressed. Objets are not really suitable for mass procesing (high DB load) therefore mass processing should be adressed.
Below are some of the advantages of OOP as you must be knowing:
Data Encapsulation
Instantiation
Code Reuse
Interfaces
Taking advantage of these, there are many important reasons for using OO ABAP "whenever possible". Even if you do not want use OO programming, using ABAP Objects is still a good idea since it provides some features that procedural programming does not.
So here's what ABAP Objects offers you over Procedural ABAP:
Better encapsulation
Support for multiple instantiation
Better techniques for reusing code
Better interfaces
An explicit event concept
There are only two purposes for which Procedural ABAP is found essential:
Encapsulation of classic screens in function modules.
When you want to make functions available to other systems, but are not able to make class methods available externally using XI server proxies. In this case, you have to use function modules.
Study about them in detail here and you will see that you don't need any significant operational/demonstrative reason to convince yourself to move to OO ABAP, coz all these reasons are already very significant.
To put it simple, use it when you have a relatively young team who are eager and ready to learn a new programming paradigm. In a senior-dominated team, adoption OO could be challenging. More so because the maintainability of the program goes down. The org may need new employees to maintain the OO code.
From a design perspective, there is no question(as a lot of people have also said in this forum) that its the best and has been in use since ages. SAP is way behind in terms of technology. Their ECC DB design is still in 2-NF. the standard 3-NF is what they've called '3D' database. No deviating too much from the main topic, I believe you now have too many good answers to reach a decision.
发布评论
评论（7）
1) 您组织中的人员何时真正开始使用 OO ABAP 进行编码？
我组织中的大多数开发人员在引入 ABAP OO 之前就已经学习了经典的 ABAP。 他们大多是高级开发人员，不愿学习正确的 OOP 和 OOD 原则。 他们仍然主要使用程序性 ABAP 功能。
此外，我们在遗留环境中工作。 我们后端的基础是在 4.6C 时代构建的。 将正确的面向对象设计引入遗留系统是很困难的。
另一方面，程序性特征仍然有效。 事务数据库更新等一些功能主要在 ABAP 的过程部分使用。 您可能知道专门用于数据库事务的更新功能模块或子例程（您可以调用
IN UPDATE TASK）。 它们是ABAP基本组件的组成部分。 不可否认，程序性ABAP 部分仍然是需要的。2）人们想要以面向对象的方式编码有什么重要的原因吗？ 例如，Call Method 比 PERFORM 语句更快？
您如何比较 CALL METHOD 与 PERFOM 的运行时间？ 您是否尝试过 RSHOWTIM 程序/或者您是否在 ABAP 工作台上进行了一些性能测试？ 单个子例程调用与方法调用没有显着差异。 但是，如果以批量测试方法调用进行调用，则性能会稍好一些（以微秒为单位）。
总的来说，我推荐OOD和OOP，其论点与之前发布的用户相同。 但你必须记住，熟悉旧ABAP世界的高级开发人员在开始编写ABAP OO之前必须了解OO原则。
否则，您的组织将不会从 ABAP OO 中获益，相反。 有很多经验丰富的 ABAP 开发人员在没有 OO 知识的情况下被迫编写类。 他们所做的实际上是模仿类的程序原理（例如，专门具有静态方法的类 - 作为功能模块/子例程的替代品）。
祝您的组织在 ABAP OO 挑战中好运！ 这与语言无关，更多的是让 OO 原则深入员工的脑海。
1) When do people in your organization actually started coding in OO ABAP?
Most developers in my organisation have learnt the classic ABAP before introduction of ABAP OO. They are mostly senior developers who restrain from learning proper OOP and OOD principles. They are still using mostly procedural ABAP features.
Furthermore, we work in a legacy environment. the basics of our backend was build during the times of 4.6C. It is hard to bring proper OO Design into legacy systems.
On the other hand, the procedural features still work. Some features like transactional database updates are mostly used from the procedural part of ABAP. You might know Update Function Modules or Subroutines exclusively for database transactions (those you can call
IN UPDATE TASK). They are an integral part of the ABAP basic components. One can't deny that the procedural ABAP part is still needed.2) Is there any significant reason that people would want to code it in an OO way? e.g. Call Method is faster than a PERFORM statement?
How did you compare the runtime of CALL METHOD vs. PERFOM? Did you try the program RSHOWTIM / Or have you done some performance tests from the ABAP workbench? A single subroutine call does not differ significantly from a method invocation. However, if called in mass test method invocations have a slightly better performance (in the magnitude of microseconds).
On the whole, I recommend OOD and OOP with the same arguments as the users who posted before. But you have to keep in mind that senior developers familiar with the old ABAP world have to understand OO principles before they start writing ABAP OO.
Otherwise, your organization would not profit by ABAP OO, on the contrary. There are a lot of experienced ABAP developers without OO knowledge who were pushed to write classes. What they do is actually mimicking procedural principles with classes (e.g. a class with static methods exclusively - as a substitute for function modules/subroutines).
Best of luck for your organisation for your challenge with ABAP OO! It is not about the language, it is more about getting OO principles into the mind of your staff.
我不了解 ABAP，但我看到 VB 开发人员迁移到 .Net 平台时也发生了同样的情况。
程序员对旧的编程方式感到满意，而且旧的方式仍然有效。 新的编程方式需要大量投资，不仅来自公司，还来自那些必须走出舒适区进入不确定领域的人们。 如果你的公司不愿意投资培训和研究时间，这个问题就会变得更大，因为人们必须投入自己的时间，但并不是每个人都愿意这样做。
正如 Taurean 已经表明的那样，有令人信服的理由转向面向对象的做事方式。 它们主要不是关于性能，而是关于更好地解耦系统中的组件，使其更易于维护。
但根据我的经验，很难用这样合理的论据说服人们走出他们的舒适区。 为他们指明道路通常效果更好。 慢慢地开始在你自己的代码中使用面向对象的结构，向人们展示它看起来多么干净。 这不是几个月就能实现的目标，可能需要数年时间才能让人们以不同的方式思考和工作。
I don't know about ABAP, but I have seen the same happen with VB developers moving to the .Net platform.
Programmers are comfortable in their old way of programming, and the old way still works. The new way of programming takes a lot of investment, not only from the company but also from people who have to move out of their comfort zone into uncertain territory. If your company is unwilling to invest in training and time for research this problem will get bigger because people will have to invest their own time, not everyone is willing to do that.
As Taurean already showed there are convincing reasons to move to the OO way of doing things. They're mostly not about performance but about better decoupling of components in your system making it far more maintainable.
But in my experience its hard to convince people to move out of their comfort zone using reasonable arguments like that. It usually works better to show them the way. Slowly start using OO constructs in your own code, show people how clean it looks. This isn't something you'll achieve in months, it can take years to get people to think and work differently.
由经验丰富的过程开发人员组成的团队不太可能很快开始以 OO 风格进行开发，除非付出大量（且昂贵）的努力来培训和指导他们。
原因有很多：
因此，他们的新代码很可能是程序性的，但在类和方法中。 他们不会对面向对象的优点印象深刻。
A team of experienced procedural developers is unlikely to start developing in an OO style anytime soon, unless a significant (and expensive) effort is made to train and coach them.
There are numerous reasons for that:
As a consequence, their new code will most likely be procedural but in classes and methods. They will not be impressed by the advantages of OO.
切换到 ABAP OO 的一些充分理由是：
添加此Taurean 列出的好处：
开始使用 ABAP OO：
CL_ABAP*或CL_GUI_FRONTEND*类中的一些标准方法资源：
Some good reasons to switch to ABAP OO is:
Add this to the benefits listed by Taurean:
Starting to use ABAP OO:
CL_ABAP*orCL_GUI_FRONTEND*classesResources:
OO与否OO不是问题！！
问题是哪里 OO 和哪里 NOT OO 。
只要您处于客户名称空间中，就可以充分利用 OO 方法（OOD 和 OOP）的所有优点。 然而，每次访问 SAP 标准功能都会带来巨大的麻烦。
事务完整性、对象一致性和同步、数据库提交、屏幕（模块池和选择屏幕）、权限检查、批量输入。 这些只是一些很难（甚至不可能）集成到 OO 方法中的对象。 SAP 标准模块的集成使这一问题变得更加复杂。
用户退出、事件：
大多数数据都是在界面中提供的。 对客户特定数据或定制的访问可以放置在对象中。
报告：大部分数据将通过标准 FM 读取。 具体的数据处理可以放在对象中。 可以轻松地在其他报告中重复使用。 SAP Enjoy 控件可以用对象外壳封装，以便于使用和重用。 屏幕不能放置在物体中。 :-(((
核心处理：SAP 不鼓励更换 SAP 业务对象维护或 SAP 流程。但如果这是一个耐心的情况，并准备好付出巨大的努力。让我们仔细看看。有很多技术挑战：单例模式、数据库访问优化、锁定、同步等。应解决技术和业务功能的分离问题。对象并不真正适合大规模处理（高数据库负载），因此应解决大规模处理问题。
OO or not OO is not a question!!
Question is where OO and where NOT OO .
All advantages of OO approach (OOD and OOP) can be fully exploited as long as you are in customer name space. However every access to SAP standard functionality creates huge headaches.
Transactional integrity, object consistency and synchronisation, DB commits, screens (module pools and selection screens), authority checks, batch-input. These are just some of objects that is difficult (or even impossible) to integrate in OO approach. Integration of SAP standard modules moves this to even higher level of complexity.
User-exits, Events:
Most of data are provides in interface. Access to customer specific data or customisation can be placed in objects.
Reports: Most of data will be read by standard FM. Specific data processing can be placed in objects. Can be easy reused in others reports. SAP enjoy controls can be wrapped with object shell for easy using und reusing. Screens can NOT be palces in objects. :-(((
Core processing: Replacing of SAP business object maintenance or SAP processes is not encouraged by SAP. But if this is a case by patient and ready for huge effort. Lets look closer. There are a lot of technichal challanges: singleton pattern, optimisation of DB access, locking, synchronisation, etc. Separation of technical and business functionality should be adressed. Objets are not really suitable for mass procesing (high DB load) therefore mass processing should be adressed.
以下是您必须了解的 OOP 的一些优点：
利用这些优势，“只要有可能”就使用 OO ABAP 有很多重要原因。 即使您不想使用 OO 编程，使用 ABAP 对象仍然是一个好主意，因为它提供了一些过程式编程所没有的功能。
因此，ABAP 对象为您提供的相对于过程式 ABAP 的功能如下：
过程式 ABAP 只有两个目的是必要的：
功能模块。
可用于其他系统，但
无法创建类方法
使用 XI 服务器在外部可用
代理。 在这种情况下，你必须
使用功能模块。
详细研究它们 这里，你会发现你不需要任何重要的操作/演示理由来说服自己转向面向对象的ABAP，因为所有这些理由已经非常重要了。
Below are some of the advantages of OOP as you must be knowing:
Taking advantage of these, there are many important reasons for using OO ABAP "whenever possible". Even if you do not want use OO programming, using ABAP Objects is still a good idea since it provides some features that procedural programming does not.
So here's what ABAP Objects offers you over Procedural ABAP:
There are only two purposes for which Procedural ABAP is found essential:
function modules.
available to other systems, but are
not able to make class methods
available externally using XI server
proxies. In this case, you have to
use function modules.
Study about them in detail here and you will see that you don't need any significant operational/demonstrative reason to convince yourself to move to OO ABAP, coz all these reasons are already very significant.
简而言之，当您有一个相对年轻的团队，他们渴望并准备好学习新的编程范例时，请使用它。 在一个由高层主导的团队中，采用面向对象可能具有挑战性。 更是如此，因为程序的可维护性下降了。 组织可能需要新员工来维护 OO 代码。
从设计的角度来看，毫无疑问（正如很多人在这个论坛上也说过的那样）它是最好的并且已经使用了很多年。 SAP在技术方面远远落后。 他们的ECC DB设计仍然是2-NF。 标准 3-NF 就是他们所说的“3D”数据库。
不要偏离主题太多，我相信你现在已经有了太多好的答案来做出决定。
To put it simple, use it when you have a relatively young team who are eager and ready to learn a new programming paradigm. In a senior-dominated team, adoption OO could be challenging. More so because the maintainability of the program goes down. The org may need new employees to maintain the OO code.
From a design perspective, there is no question(as a lot of people have also said in this forum) that its the best and has been in use since ages. SAP is way behind in terms of technology. Their ECC DB design is still in 2-NF. the standard 3-NF is what they've called '3D' database.
No deviating too much from the main topic, I believe you now have too many good answers to reach a decision.