Розглянемо приклад нижче. Будь-яка зміна перерахунку ColorChoice впливає на всі підкласи IWindowColor.
Чи викликають перерахунки крихкі інтерфейси? Чи є щось краще, ніж ентум, щоб дозволити більше поліморфної гнучкості?
enum class ColorChoice
{
Blue = 0,
Red = 1
};
class IWindowColor
{
public:
ColorChoice getColor() const=0;
void setColor( const ColorChoice value )=0;
};Редагувати: вибачте за використання кольору в якості мого прикладу, про це не йдеться. Ось інший приклад, який уникає червоної оселедця і надає більше інформації про те, що я маю на увазі під гнучкістю.
enum class CharacterType
{
orc = 0,
elf = 1
};
class ISomethingThatNeedsToKnowWhatTypeOfCharacter
{
public:
CharacterType getCharacterType() const;
void setCharacterType( const CharacterType value );
};Далі, уявіть, що обробляється відповідним підкласом ISomethingThatNeedsToKnowWhatTypeOfCharacter, що подається за заводською схемою дизайну. Тепер у мене є API, який не можна розширити в майбутньому для іншого додатка, де допустимі типи символів {human, dwarf}.
Редагувати: Просто щоб бути більш конкретним щодо того, над чим я працюю. Я розробляю сильну прив'язку цієї специфікації ( MusicXML ), і я використовую класи перерахувань для представлення тих типів у специфікації, які оголошені за допомогою xs: перерахування. Я намагаюся подумати про те, що станеться, коли вийде наступна версія (4.0). Чи може моя бібліотека класів працювати в режимі 3.0 та в режимі 4.0? Якщо наступна версія на 100% відстала назад, можливо, можливо. Але якщо значення перерахування були вилучені із специфікації, то я мертвий у воді.