Considere o exemplo abaixo. Qualquer alteração na enumeração ColorChoice afeta todas as subclasses IWindowColor.
As enums tendem a causar interfaces quebradiças? Existe algo melhor que um enum para permitir mais flexibilidade polimórfica?
enum class ColorChoice
{
Blue = 0,
Red = 1
};
class IWindowColor
{
public:
ColorChoice getColor() const=0;
void setColor( const ColorChoice value )=0;
};
Edit: desculpe por usar cores como meu exemplo, não é disso que se trata. Aqui está um exemplo diferente que evita o arenque vermelho e fornece mais informações sobre o que quero dizer com flexibilidade.
enum class CharacterType
{
orc = 0,
elf = 1
};
class ISomethingThatNeedsToKnowWhatTypeOfCharacter
{
public:
CharacterType getCharacterType() const;
void setCharacterType( const CharacterType value );
};
Além disso, imagine que os identificadores da subclasse ISomethingThatNeedsToKnowWhatTypeOfCharacter apropriado sejam distribuídos por um padrão de design de fábrica. Agora eu tenho uma API que não pode ser estendida no futuro para um aplicativo diferente em que os tipos de caracteres permitidos sejam {human, dwarf}.
Edit: Apenas para ser mais concreto sobre o que estou trabalhando. Estou projetando uma forte ligação a essa especificação ( MusicXML ) e estou usando classes enum para representar os tipos na especificação que são declarados com xs: enumeração. Estou tentando pensar no que acontece quando a próxima versão (4.0) for lançada. Minha biblioteca de classes poderia funcionar no modo 3.0 e no modo 4.0? Se a próxima versão for 100% compatível com versões anteriores, talvez seja. Mas se os valores de enumeração foram removidos da especificação, eu estou morto na água.