Porém existem algumas situações em que a utilização de enumerações é desaconselhada na representação de um estado. A primeira é quando é desejável que o estado seja um ponto de extensão e que novos estados possam ser definidos. Nesse caso, como os possíveis estados são definidos dentro de uma enumeração fixa, não se pode adicionar um novo sem a modificação do código do próprio enum. Outra situação é quando algum estado precisa armazenar uma informação específica do objeto que está sendo composto por ele. Nesse caso, como cada instância do enum é compartilhada por todos que a possuem, a informação não poderia ser diferente para cada uma. No exemplo apresentado, os nós já possuíam um estado explícito segundo a descrição do algoritmo, porém um cenário para utilização do padrão State muitas vezes é difícil de ser identificado inicialmente. O conceito do que significa um estado para uma determinada entidade do software pode começar a ficar explícito somente no momento da codificação. A repetição de condicionais similares em diversos pontos da mesma classe pode ser um sinal de que seria adequada a refatoração do código em direção ao padrão State. O mesmo vale para outros padrões que utilizam composição. Um exemplo é quando uma classe possuir um método grande que utiliza condicionais para selecionar dentre alternativas de implementação para um mesmo algoritmo. Nesse caso, a refatoração poderia ser na direção do padrão Strategy.