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.