Executando verificação de segurança...
10

Sim, essa é uma solução válida e já usei diversas vezes, e pode até deixar o código mais legível (limpo).

Mas é bom alertar para o fato que ela é menos performática, e pode confundir alguns (o que eu não me importo muito, desde que não confunda quem sabe programar, que é o que importa, se não for um código tutorial).

Claro que você pode não se importar com a performance, porque afinal é JavaScript, que foi feito para rodar scripts e não aplicaçãoes pesadas, porque se estiver rodando isso provavelmente a escolha da linguagemfoi errada. E também provalmente está rodando em um browser, o que importa pouco, mas muita gente já roda JS em servidor, e nenhum problema se a performance não é importante, ele costuma ser em média 10x mais lento que outras tecnologias por várias razões (não estou pegando o melhor caso nem o pior).

Se a performance não importa, o fato da hash table ser O(1) nem importa muito (na verdade o pior caso é O(n), mas ele quase nunca ocorre, em alguns casos ele é só um pouco superior a O(1), e em muitos ele é efetivamente O(1)). E ser O(1) não é mesma coisa de ser rápido. Dois algoritmos O(1) que fazem a mesma coisa podem ter velocidades efetivas muito díspares, o Big O só demonstra a relação de velocidade em relação a quantidade de elemntos com potencial de serem processados.

Ao mesmo tempo que em alguns casos, especialmente com muitas opções, que o if pode ser mais lento, porque ele, no pior caso, será O(n). Mas novamente, cada elemento será bem mais aconômico que pegar um elmento na hash table, o problema é que ele terá que fazer em vários, então a conta não é simples.

Nem falei da questão que a hash table colocará pressão no garbage collector e isso trará mais custo de performance e se você não souber fazer um benchmark adequadamente pode nem pegar esse custo.

Reforçando que isso vale para quando a performance importa.

A questão de ser mais fácil de manter e ser elegante não é tão simples, até porque pode ser subjetivo, principalmente o segundo exemplo pode ser mais difícil, pelo menos para alguns.

Quando mudamos para um switch, a seleção por código começa ter mais vantagens e é uma pena que a sintaxe do JS não ajude mais como outras linguagens que tem uma pegada mais funcional, incluindo Java e C#, não só as (quase) completamente funcionais. E eu não sei as otimizações que cada engine de JS faz para falar sobre a performance dele, em algumas implmentações de linguagens o switch pode ser O(1), o que não quer dizer que será necessariamente mais rápido do que o if. Só de colocar o returnna mesma linha do if e não usar chaves já ajuda um pouco o código ficar mais curto.

Com um bom switch eu evitaria completamente o uso de hash tables em quase todos os casos, mas novamente, para JS isso não importa muito.

Aí temos uma lição para aprender. Se usamos JS como ele foi concebido originalmente, qualquer pode ser feita porque é algo simples e a performance não importa, mas quando usamos como a maioria usa hoje para algo mais complexo e que pode precisar de performance, JS pode não ser a melhor opção, apesar e atender a demanda. Sei que isso não vai agradar muita gente, mas estou falando olhando todos os aspectos da engenharia. Clar oque eu entendo que as decisões de qual linguagem usar passa muito por mercado e outras questões que não são de engenharia.

S2


Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).

Carregando publicação patrocinada...
1

E no caso de usar o new Map() eu uso bastante para alguns casos, alguma vantagem?
Nesse caso de retornar um texto eu até usaria um enum descritivo.
Mas por exemplo com Map:

const orderStatusMap = new Map([
    ["pending", "Seu pedido está em análise"],
    ["processing", "Seu pedido está sendo preparado"],
]);

orderStatusMap.get("pending");
1

Nesse exemplo só aumentou a complexidade da leitura.
Se você tem uma estrutura que vai crescer, use o Map. Se tem uma estrutura estática, prefira o object {}.
Há muitos artigos de testes de benchmark mostrando a diferença e casos de uso.

1

Map é uma hash table, é praticamente a mesma coisa. Eu não sei se a implementação interna é um pouco diferente em JS, mas a base é a mesma, tem linguagens que a implementação é idêntica, uma é só syntax sugar de outra.

1

Prefiro:

// Definindo o enum de status
const OrderStatus = Object.freeze({
  PENDING: 'pending',
  PROCESSING: 'processing',
  SHIPPED: 'shipped',
  DELIVERED: 'delivered',
  CANCELED: 'canceled',
});

// Mapeando mensagens para os status
const statusMessages = Object.freeze({
  [OrderStatus.PENDING]: 'Seu pedido está em análise.',
  [OrderStatus.PROCESSING]: 'Seu pedido está sendo preparado.',
  [OrderStatus.SHIPPED]: 'Seu pedido foi enviado.',
  [OrderStatus.DELIVERED]: 'Seu pedido foi entregue!',
  [OrderStatus.CANCELED]: 'Seu pedido foi cancelado.',
});

// Função usando o mapa de mensagens
function getOrderStatusMessage(orderStatus) {
  return statusMessages[orderStatus] || 'Status desconhecido';
}

// Testes
console.log(getOrderStatusMessage(OrderStatus.PENDING)); // "Seu pedido está em análise."
console.log(getOrderStatusMessage(OrderStatus.SHIPPED)); // "Seu pedido foi enviado."
console.log(getOrderStatusMessage('unknown')); // "Status desconhecido"
1
1

Finalmente uma resposta adequada.
Vejo muito o pessoal adicionando complexidade no que foi concebido para ser simples e performático.
Um if com return sem precisar de else if, já melhora a legibilidade.
O switch case então... Para ler um código de cima pra baixo fica muito simples do que ter que mapear uma outra estrutura de objetos apenas por conveniência. Fora que ele foi concebido pra isso. O compilador otimizará o máximo possível para performá-lo.