输入通用接口方法参数以使接口更易于访问的优缺点是什么？

如何解决输入通用接口方法参数以使接口更易于访问的优缺点是什么？

我有一个应用程序，它使用许多不同的简单转换以及许多不同的 abap 结构从 abap 结构创建 xml 字符串。

我想使用更灵活的面向对象方法和接口来做到这一点，但由于结构不同，方法签名导入参数总是不同的。

键入导入参数泛型以便我可以从处理不同转换的每个类中的一个接口实现一个方法有什么优点和缺点？

INTERFACE if_transformer.
  METHODS transform_xml
    IMPORTING isource_structure TYPE REF TO data
    RETURNING VALUE(rxml_string) TYPE string.
ENDINTERFACE. 

...

CLASS material_transformer definition.
  PUBLIC SECTION.
    INTERFACES if_transformer.
ENDCLASS.

CLASS material_transformer IMPLEMENTATION.
METHOD if_transformer~transform_xml.
  FIELD-SYMBOLS <structure> TYPE concrete_structure.
  ASSIGN isource_structure->* TO <structure>.
  ...
ENDMETHOD.
ENDCLASS.

  

解决方法

您的类型越具体，您越早发现错误，您的接口就越容易被理解，并且您在验证和转换/转换为您想要处理的具体类型方面的开销也就越少。

例如，假设您将方法 add_number 键入为 methods add_number importing n type i。然后编译器将拒绝错误的语句 add_number( 'xyz' ) 并且此类错误永远不会使其成为可执行代码。反过来，任何阅读该方法声明的人都可以很容易地看到该方法只接受整数，不接受浮点数，不接受压缩，绝对不接受包含数字的字符串。在该方法中，您可能可以直接获取输入 n 并对其进行处理，例如 result = sum_so_far + n，而无需先验证输入或将其转换为其他内容。

相反，假设您键入与 add_number 相同的方法 methods add_number importing n type ref to data。编译器很乐意接受 add_number( ref #( 'xyz' ) )，尽管它完全是胡说八道；因此，此类错误只会在运行时检测到，类型转换异常，围绕此的代码必须以有意义的方式做出反应。阅读方法声明的人必须查阅它的文档、单元测试和/或代码，以找出它接受什么样的输入；仅从规范中无法猜测它。最后，在该方法中，您必须先验证和转换输入，然后才能对其进行处理，例如 is_integer( n )、cast、assign 等；如果输入不可接受，您需要找到合适的错误处理机制，例如抛出好的异常。

对于像 JavaScript 这样的软类型语言，默认使用泛型类型。然而，历史表明人们通常更喜欢更强的类型，至少在服务器端，导致后续的演变，如 TypeScript 或 Deno。对于像 ABAP 这样的强类型语言，经验法则是选择尽可能精确的数据类型。

请注意，泛型类型有几个级别的放松。例如，在使用最大泛型类型 simple 之前，您应该考虑使用“部分”泛型类型，例如 standard table，它接受​​ ABAP 结构，或 data，它接受​​表。

,

弗洛里安的精彩回答。我可能要补充一点，我在类似场景中使用的一种方法是使用工厂类来检查输入数据并实例化适当的类来处理它。