1

我想重用通常属于顶部包含的选择屏幕或数据/类型声明上的元素。我有几个报告在选择屏幕上共享几个元素。相同的报告共享有关应用程序日志的各种数据元素，因此存在可重用性问题。

由于 SAP 编程指南指出

不要多次使用包含程序。

使用包含程序对一个主程序进行模块化。

我们强烈建议只使用合适的重用方式，例如全局类或接口

我正在寻找替代方案来实现我的目标。

我能想到为此使用全局类的唯一方法是定义类属性而不是数据声明并将它们用作变量。

class->Attribute = desired_value

这似乎有点奇怪，尽管非常接近类用于常量的方式。另一方面，我可以在 DDIC 中创建一个结构，其中包含所有所需的声明作为组件。

宏将是我的最后一个想法，也是唯一一个关于选择屏幕元素的想法。


DEFINE test.
  PARAMETERS: pa_delta TYPE c AS CHECKBOX.
  PARAMETERS: pa_date TYPE dats.
END-OF-DEFINITION.

TABLES: lfb1.

SELECT-OPTIONS: so_lifnr FOR lfb1-lifnr.
SELECT-OPTIONS: so_bukrs FOR lfb1-bukrs.

test.

你将如何解决这个问题？

4

2 回答 2

3

对于类型，您当然应该使用类或接口而不是包含以进行重用。

interface ZIF_DEMO
  public .
   types: begin of myType,
            a type flag,
            b type i,
          end of myType.

endinterface.


REPORT zdemotype.
data gs type zif_demo=>mytype.
select-OPTIONS: s_a for gs-a.

至于选择画面的再利用。这有点难以避免。

有关一些想法，请参阅报告 demo_call_selection_screen 。
如果您有许多需要此类功能的程序，您可以从另一个提交一份报告。或者有一个带有初始化逻辑的选择屏幕的报告。

请注意，语句提交还支持对特定选择屏幕的引用。

submit demo_call_selection_screen USING SELECTION-SCREEN '100'  and return.

当然，这提出了一个问题，您是要运行程序还是只是重用屏幕。在这种情况下，您需要通过内存返回选择屏幕内容。在这种情况下，类似的功能RS_SELECTIONSCREEN_READ将被证明是有用的。事实上，如果对这个主题感兴趣，整个功能组ALDB 都值得一看。

但是，如果我有多个报告问题，这些问题使用了类似和大的选择选项，这些选项在某种程度上是部分常见和一致的，我会使用 1 个驱动程序，它只是调用类中的不同功能。

如果屏幕不是那么复杂，只需复制选择屏幕代码。在此之前，您关注了多少 DRY 问题。

就我个人而言，如果在进行代码审查时看到 10 个程序有 1 个通用包含，而其中唯一的东西是一个选择屏幕，没有数据语句类型或代码，我可能会继续前进。尤其是如果它包含关于为什么需要一个通用选择屏幕的评论，并且其余程序结构良好。指导方针就是指导方针。可维护性和健壮性无疑是目标。作为ABAPER，您可能会犯下更大的罪过:)

于 2019-09-11T22:51:41.543 回答
2

对于选择屏幕元素，您可以简单地定义subscreens。如果元素在同一个程序的多个选择屏幕中，您也可以选择屏幕包含。

变量和类型可以通过将它们建模为类和接口来重用。如果您只是将它们之间没有关系的变量放在一个类或接口中，那么这只是一个坏主意，我想说也许定义一个包含程序并不是最糟糕的主意。

但是，由于您只公开了最后一个问题（对于我们不知道的原始问题，您只有一个解决方案），因此很难提供更好的帮助......

于 2019-09-12T12:25:14.517 回答