这是关于迁移函数组的系列文章的第3部分。

开始博客是第1部分，共3部分

现在我将讨论调用程序中使用新代码工件所需的调整。

调用程序调整与函数组更改

必须使用所有这些创建的类。否则整个活动就没有意义了。

需要修改/删除以前的功能组，以避免代码重复。

有两种方法都是有用的。

此方法用于无法完全迁移的功能组/模块。举例来说，开始云，数据挖掘和大数据，RFC功能模块可以用这种方法改变。

几乎所有的功能组都应该删除。所有函数模块都应该更改为只调用新类的相关方法。这种方法遵循编程指导原则"功能模块和子例程中没有实现"https://help.sap.com/doc/abapdocu\u 751\u index\u htm/7.51/en-US/index.htm？文件=ABAU异常_消息.htm.

功能组"ZFG1"有一个名为"ZFG1\ U FM1"的功能模块。它有两个异常"NOT \u FOUND"和"SOME \u ERROR"。

生成了一个类"ZCL \u FG1"，方法为"ZIF \u FG1~M1"。生成了一个异常类zcx\u fg1。

现在只调用方法的功能模块实现的交换影响最小，51返利，因为几乎不需要调整调用方。这些功能模块的动态调用大多是开箱即用。

调用方的可测试性没有提高。这种方法无法解决消除代码样式复杂性的任务。它甚至不能解决一开始提到的隐式增强的问题：表单例程的增强和函数组的其他组件（如全局变量）的使用被破坏。

调整调用者调用新方法，而不是以前使用的函数模块。在所有的功能模块中，功能模块/功能组应该被删除或设置为过时。

一个方法ZCL\U调用者->m2调用以前的功能模块"ZFG\U FM1"（见上面的例子）。

ZCL\U fg1的后期实例化也是可能的。

一个人应该考虑不要用一个特定的方法封装这个方法调用try-catch块，但如果可行的话，可以有一个大的try-catch块。

更好的方法是对调用程序中基于类的异常进行自适应。

在调用程序中启用生成类的模拟，提高可测试性。避免在过程和基于类的代码样式之间跳跃。提高了性能，淘客联盟，因为使用时不必加载任何功能组，调用堆栈中的条目也少了一个。

如果经常调用功能模块，可能会导致相当大的工作量。为了简化这个过程，重构工作台可以显示一个where used列表。自动适应是有问题的，大数据主要学什么，因为只有在功能组以自下而上的方式转换时，这才有帮助。每个调用者都必须决定如何适应异常处理。