要在ABAP中表示固定值集，可以使用几种不同的技术。最新的一个是枚举，它是在语言级别提供的，可以作为ABAP7.51使用。通过这篇博文，我想展示ABAP开发人员有哪些可能性来定义枚举并以最安全的方式在签名元素中使用它们。

枚举使您能够为编程语言的类型系统中的特定上下文定义固定数量的命名值。它们的行为类似于常量，但还有一个附加特性，即仅限于定义的值（而不限于常量的类型）。这在使用枚举定义形式参数时特别有用，因为这样API的用户就不太可能错误地使用方法（因为类型系统不允许它，这将是一个编译时错误）。

请考虑以下示例：

对于我们大多数人来说，很明显iv_on应该是""或"X"，因为参数的类型是abap_bool。所以典型的用法是这样的（首选使用abap常数）：

但是，类型系统不会强制您使用""或"X"，因为abap\u bool只是全局类型池abap中的一个类型定义，物联网的前景，它的实际类型是长度为1的C。

这意味着以下情况不会导致编译器错误：

但是它可能会导致方法实现中的错误，因为实现它不希望有人使用"A"作为实际参数，因为按照约定只应使用""和"X"。对于abap\u bool来说，这可能没什么问题，因为大多数开发人员都知道abap在构建布尔类型中的缺失及其解决方法。但是，其他特定于模块/应用程序或您自己定义的类型呢？

假设我们有更多的状态，而不仅仅是真假。我们的灯现在不仅开或关，而且可以显示不同的颜色（如红绿灯）。

枚举值作为常量

如果我们现在想使用常量（如abap\u true和abap\u false），我们必须自己定义它们。但是我们在哪里做呢？有三种不同类型的开发对象可供使用：

类型池：如SLI、OSCON、ABAP…接口：如IF_SALV_C∗*，在BOPF中生成的接口…类：或者直接在类中使用需要常量的方法，或者在它自己的方法中，比如CL\u GUI\u CONTROL=>METRIC\u PIXEL

由于类型池已经过时，接口（或者类）是现在的发展方向。下面是一个使用常量接口的示例：

正如您所看到的，API的用户在方法文档中被指向常量接口，大数据专业，并且被导入参数的类型所指示。接口中gty\u light\u state的类型声明通常是不必要的（因为内置的类型I当然已经存在），但是它有助于引用存储常量的位置。当然，您也可以创建一个DDIC数据元素，并在其描述中引用接口。但是如果没有文档记录，API用户将被迫查看方法的实现，以找出要使用的实际参数（这很麻烦，也不总是可能的，请考虑在没有实现的接口中定义方法）。

因此，现在可能的值是已知的，但仍然是开发人员实现的方法（并使用契约式设计原则）应该验证调用者的实际参数。这意味着检查它是否是常数之一。在上面的示例中，这是使用范围表完成的。你可以看到这里的另一个弱点。如果一个人决定将另一个状态添加到红绿灯（如黄色闪烁），验证逻辑将必须更新，即使该方法的其余部分可以很好地处理另一个状态。

将接口用于常量定义的一个优点或缺点是，您可以在使用它们的类中实现接口。这使您能够直接访问常量（只要您定义了别名）。另一方面，如果您在members视图中检查对象实例，您还可以在调试器中找到接口定义的所有内容。我个人不喜欢这样做。

DDIC域值

另一种方法是使用数据字典中的域。一开始这些似乎特别适合这个任务。如果变量的值是在域中使用标准函数模块或RTTI定义的，则可以轻松地进行验证。这里是使用域（/引用域的数据元素）的同一个light switcher类：

但是，要记住的一点是，没有方法以静态方式引用每个值（因为它们必须首先从数据库中获取）。这有时会导致一种情况，即你有一个域和常数，你必须保持同步。例如在CASE语句中。一个优点是，你可以使用传统的dynpro值帮助/你得到他们"免费"的本地化支持（以及域附件）。

使用新的7.51枚举

因为ABAP7.51有一个语言级别的构造，正好适用于这里描述的用例。SAP选择的实现（令我惊讶的是）是"基于值类型"的，而不是像许多其他语言（如Java或C#）那样面向对象。简而言之：通过定义一个枚举，您可以定义一个类型（确切地说是值类型）及其关联的常量，如果您自己不这样做，它会隐式地获得赋值。此外，如果使用或不使用关联的常量，则对类型化为枚举类型的数据对象的任何赋值都将得到编译时检查。否则会导致语法错误。

很遗憾，有享云商城，我无法访问7.51系统（如ABAP7.51开发者版，您在哪里？）但看看文档，它应该是这样工作的：

在我看来，这些应该取代所有用例中的接口常数，只要您不必担心向后兼容性。