No seu código, você fez várias alterações:
-
A atribuição de desestruturação
- para acessar campos no
pages
é uma boa mudança. - extrair as funções
parseFoo()
, etc., é possivelmente uma boa mudança. - introduzir um functor é… muito confuso.
Uma das partes mais confusas aqui é como você está misturando programação funcional e imperativa. Com o seu functor você não está realmente transformando dados, você está usando para passar uma lista mutável através de várias funções. Isso não parece uma abstração muito útil, já temos variáveis para isso. A coisa que possivelmente deveria ter sido abstraída - analisando apenas esse item, se existir - ainda está lá em seu código explicitamente, mas agora temos que pensar na esquina. Por exemplo, é um tanto não óbvio que parseFoo(foo)
retornará uma função. O JavaScript não possui um sistema de tipo estático para notificá-lo se isso é legal, portanto, esse código é propenso a erros sem um nome melhor ( makeFooParser(foo)
?). Eu não vejo nenhum benefício neste ofuscação.
O que eu esperaria ver em vez disso:
if (foo) parseFoo(pages, foo);
if (bars) parseBar(pages, bars);
if (bazes) parseBaz(pages, bazes);
return pages;
Mas isso também não é ideal, porque não está claro no site de chamada que os itens serão adicionados à lista de páginas. Se, em vez disso, as funções de análise forem puras e retornar uma lista (possivelmente vazia) que possamos incluir explicitamente nas páginas, isso pode ser melhor:
pages.addAll(parseFoo(foo));
pages.addAll(parseBar(bars));
pages.addAll(parseBaz(bazes));
return pages;
Benefício adicionado: a lógica sobre o que fazer quando o item está vazio foi agora movida para as funções de análise individuais. Se isso não for apropriado, você ainda pode introduzir condicionais. A mutabilidade da lista pages
agora é reunida em uma única função, em vez de propagá-la em várias chamadas. Evitar mutações não locais é uma parte muito maior da programação funcional do que abstrações com nomes engraçados como Monad
.
Então, sim, seu código foi muito inteligente. Por favor, aplique sua esperteza para não escrever código inteligente, mas para encontrar maneiras inteligentes de evitar a necessidade de esperteza grosseira. Os melhores designs não parecem elegantes , mas parecem óbvios para quem os vê. E boas abstrações estão lá para simplificar a programação, não para adicionar camadas extras que eu tenho que desenredar em minha mente primeiro (aqui, descobrindo que o functor é equivalente a uma variável, e pode ser efetivamente eliminado).
Por favor: em caso de dúvida, mantenha seu código simples e estúpido (princípio KISS).