共计 2001 个字符，预计需要花费 6 分钟才能阅读完成。
ABAP（Advanced Business Application Programming）泛型编程是一种在 ABAP 语言中应用的编程范式，它容许编写能够解决多种数据类型的通用代码。泛型编程的目标是进步代码的复用性、灵活性和可维护性。通过应用泛型编程，开发人员能够编写一种通用的算法或数据结构，而不用为每种数据类型编写特定的实现。
在 ABAP 中，泛型编程次要通过应用类型组（Type Groups）和泛型类型（Generic Types）来实现。类型组容许您定义一组相干的类型，而泛型类型容许您编写独立于特定类型的代码。例如，您能够编写一个泛型排序算法，该算法能够解决任何类型的数组，而无需为每种类型的数组编写独自的排序函数。
以下是 ABAP 泛型编程的一些要害概念：
- 类型组（Type Groups）：类型组是一种组织和治理相干类型的办法。您能够应用 TYPE-POOL 关键字定义类型组，而后在程序中应用它们。类型组提供了一种定义类型别名和常量的办法，以便在整个程序中重复使用。
- 泛型类型（Generic Types）：泛型类型是一种示意不确定类型的办法。这容许您编写通用的代码，该代码能够解决多种类型的数据。在 ABAP 中，泛型类型通常用 TYPE ANY 或 TYPE ANY TABLE 示意。您能够应用泛型类型编写独立于特定类型的函数、办法和类。
- RTTS（Run Time Type Services）：RTTS 是一组用于创立和操作动静类型的 ABAP 类和接口。应用 RTTS，您能够在运行时创立、批改和查问类型信息，从而使您的代码更加灵便和可扩大。
总之，ABAP 泛型编程容许您编写可解决多种数据类型的通用代码，从而进步代码的复用性、灵活性和可维护性。这是通过应用类型组、泛型类型和 RTTS 等技术来实现的。
咱们来看事实工作中一个理论的例子。
Attachment 的 metadata 里定义的 data type 和 runtime 时的 data type 不一样
Attachment 和其余四个节点不太一样。
当用新的 service url 拜访时，https://jerry.corp:44354/sap/opu/odata/sap/CRM_ODATA/TaskColl…
动静生成的 structure 是 BP 定义的 common structure，如下：
用老的 service url：https://jerry.corp:44354/sap/opu/odata/sap/CRM_TASK/Tasks?$filter
则动静生成的 structure 是咱们 task 本人的 attachment structure。
优化后的代码须要可能同时 handle 这两种状况。我曾经想到有两种方法能够工作，等做完性能测试后再 update 大家。
不晓得 BP 是否也要实现相似的需要，如果是，等我把 solution 写进去之后再和他们的比拟。
Metadata 里是这个 structure：
Runtime 变成了这个：
这些 BPID 和 file_size 是 runtime 生成的？这个 structure 里 header_guid 也没了。
在 Z class 里调了半天才调通，两头遇到好多 dump。
有两种方法。
办法 1：如果 line 15 ASSIGN 失败，阐明以后的 internal table 类型是 BP 定义的。
其实就是通过 line 17 设置的标记位，如果是 BP 的 structure，就用 BP 的 field symbol 接，否则用 task 的 field symbol 接。
这种办法益处是速度比拟快，因为只有 1 处泛型解决。毛病是在代码里呈现了 BP 的 structure crmt_bp_odata_attachment_t.
办法 2：这种方法从间接上能发现不须要引入对 BP structure 的依赖，代码里只须要咱们本人的 attachment structure。
- 在 line 10~11 动静 assign 一个 field symbol
- 其目标是 line 23 用来接实在的 attachment 数据，而后 line 24 写回到 result container 里去。
留神这里 line 24 的两个 field symbol 都是齐全 generic 的，而且赋值在 LOOP 里实现，所以办法 2 的泛型解决次数为 1 + task 个数。
所有高级语言的 guideline 都说尽量避免泛型解决，除非没其余方法。那这两种方法性能有多少差别？因为 Zclass 里 attachment 都是 hard code 的，所以比拟的性能差别其实就是泛型解决的 overhead。
当解决 10 个 task 时，相差 300 微秒
100 个 task：办法 1 就比办法 2 快 1 倍了
500 个 task：
1000 个 task：
1 万个 task：
这时差距就甩开了，办法 2 所有操作都是在 memory 里做的，竟然也耗费了 0.2 秒。
鉴于咱们 offline 的 use case，1 千个 task 都算相当大的数据量了，这种状况下办法 2 耗费的相对工夫依然不大，所以最初我决定采纳办法 2.