'Other'-Wert in ENUMs: Ein Aufruf zur Vorsicht

Ein Fallstrick, über die viele Entwickler bei der Arbeit mit Enumerationen (ENUMs) stolpern, ist die Einführung eines 'Other'-Wertes. Ein Beitrag im Blog "The Old New Thing" von Raymond Chen macht auf diese Problematik aufmerksam und zeigt auf, wie ein solcher Wert einer Anwendung schaden kann.

Nehmen wir die folgende ENUM-Deklaration:

Hierbei wird angenommen, dass es drei Geschmacksrichtungen von Widgets gibt, aber möglicherweise in Zukunft weitere hinzukommen werden. Um auf diese Möglichkeit zu reagieren, wird ein 'Other'-Wert eingeführt, um spätere Erweiterungen zu berücksichtigen. Doch dieser Ansatz birgt erhebliche Risiken.

Stellen wir uns vor, dass in zukünftigen Versionen der ENUM ein neuer Geschmack namens 'Mint' hinzugefügt wird:

Ein Benutzer des API, der die Funktion GetWidgetFlavor aufruft und ein Mint-Widget erhält, sieht sich nun einem Dilemma gegenüber. Soll der Rückgabewert 'Mint' lauten oder wird dies die Kompatibilität mit bereits existierendem Code gefährden, der 'Other' erwartet?

Die Problematik besteht darin, dass der Begriff 'Other' impliziert, dass die ENUM vollständig ist. Der Rückgabewert 'Other' könnte für ältere Versionen des Codes als unerwartet und verwirrend angesehen werden. Chen empfiehlt daher, auf die Verwendung von 'Other' zu verzichten und stattdessen festzulegen, dass Werte, die nicht erkannt werden, als 'Other' betrachtet werden sollten.

Ein besserer Ansatz wäre es, die ENUM offen zu lassen und zu dokumentieren, dass der neue Wert 'Mint' zu einer separat definierten Kategorie zählt. Auf diese Weise können neue Implementierungen 'Mint' korrekt zurückgeben, während älterer Code die neuen Werte in einer selbst definierten 'Other'-Kategorie belässt.

Entwickler sollten also bei der Gestaltung ihrer APIs Vorsicht walten lassen.

Vorsicht bei der Implementierung von APIs mit other-Werten in Enums