Programação Funcional em JavaScript: A Aridade e Tuples

X

Privacidade e cookies

Este site usa cookies. Continuando, você aceita seu uso. Consiga mais informação; Por exemplo, sobre como controlar cookies.

entendido

anúncios

14787298814_2ED9B48A0_K.jpg

Voltando para a série Post Dedicada à programação funcional em JavaScript. Nós estamos explicando a importância do uso de métodos encadeados para obter um código mais expressivo.

No post de hoje, falaremos sobre as desvantagens que nos trazem o uso de métodos acorrentados. Vamos aprender uma nova maneira de modular nosso código e levar muito mais parte na reutilização de código através do conceito de tubos que podem ser usados em programação funcional.

vamos explicar quais são os tubos e o Características Precisamos que eles atendam às funções para poder alcançar essa sensação de código que flui por meio de um tubo conectado. Explicaremos o que é a aridade e como os toques ou o currículo podem nos ajudar a gerenciar a complexidade das altas arressados.

Como sempre, você me tem à sua disposição nos comentários, caso possa resolver qualquer uma das suas dúvidas . Vamos começar:

O problema dos métodos acorrentados

Os métodos acorrentados nos ajudam muito a escrever um código melhor. Poderíamos ver isso no capítulo anterior. Isso não muda. No entanto, encontramos um grande problema para os métodos acorrentados.

Se nos lembrarmos, por exemplo, o método ‘filtro’ do ES5, o método retorna um novo objeto de matriz que contém os métodos novamente. Daí a magia de ser capaz de concatenar. Infelizmente, o padrão é uma arma de dois gumes, já que os métodos são tão acoplados ao tipo de objeto que nos limitam nos dá muito pouca flexibilidade de reutilização.

com métodos concatenados somos obrigados a usar apenas o conjunto de operações que fornecem o próprio objeto. Seria ideal que pudéssemos quebrar essa cadeia e dentro da assembléia que poderíamos organizar funções em nosso desejo. Os métodos acorrentados não são a solução, então teremos que nos procurar outra alternativa.

Os tubos

e a alternativa vem na forma de um tubo. Se com os métodos acorrentados, perdemos expressividade e ganhando muito acoplamento, com a organização de funções em um tubo que poderíamos ter o oposto.

A chave para organizar funções em tubulações é a de ser capaz de ter um Arsenal de funções desespladas que podem ser executadas sequencialmente. Como em um tubo, nossas funções passariam estados de uma função para outra. Os parâmetros de saída de uma função suporão os parâmetros de entrada do seguinte.

Desta forma, posso criar peças de código muito independentes, que cumprem uma função específica e que por composição de suas entradas e suas partidas Pode criar um programa importante.

Se usarmos a notação usada no Haskell, podemos explicar melhor isso. Podemos definir funções desta forma:

<nombre_funcion> :: <entradas> -> <salidas>

No final, é muito semelhante a definir lambdas, apenas neste caso, estamos mais interessados em saber o que Tipos de dados Enter e eles deixam uma função. É a especificação de uma caixa preta.

Eu vi isso, vamos ver um exemplo. Eu posso compor por meio de pipelines As seguintes funções:

f :: A -> Bg :: B -> C

Onde f e g são o nome de uma função e A, B e C são diferentes tipos. Nesse caso, como a saída de f corresponde ao tipo de B. Eu poderia executá-los como se fosse um tubo:

g(f(A)); // donde se devuelve C

Isso à primeira vista parece óbvio, você pode nos ajudar muito. Não será fácil obter isso em ambientes mais complexos, pois haverá funções que retornam objetos que não podem ser reutilizados.

No entanto, é algo que temos para levar em conta ao projetar funções. É importante ver que precisamos fazer funções compatíveis entre si. Para conscientização sobre isso no processo de design, é importante que consideremos dois fatores: a compatibilidade dos tipos de insumos e saídas e a concessão das funções.

Tipo compatibilidade

como Vamos dizer, a compatibilidade do tipo refere-se aos tipos de saída de função relacionadas aos tipos de parâmetros de entrada de outro. Não é um problema que temos que nos preocupar muito em JavaScript, porque no final quando se encontra com linguagem fracamente típica, podemos ter muito mais flexibilidade.

No final Isto é o que é geralmente chamado de “tipos de pato”, não estou interessado em tubos JavaScript tanto que os tipos são idênticos e que o objeto que retorna uma função, se comporta como o tipo de O parâmetro de entrada à espera da minha próxima função. Isto é, se for como um pato e Grazna como um pato, é um pato. Se um objeto se comportar um tipo específico e tiver os atributos que eu espero nesse tipo, para mim é esse cara. É a coisa boa e a coisa ruim sobre JavaScript.

Se quiséssemos tornar nossas funções estritamente compatíveis, uma boa ideia seria usar o tipografia. Deixo a bate-papo de Micael Galician novamente aqui caso você esteja interessado nesta alternativa.

Portanto, quando projetamos funções, temos que ter claro os caras com os quais nossas funções jogam. Imagine que queremos fazer um sistema que dado um número de identidade, removemos os espaços e scripts para trabalhar melhor com ele. Vamos projetar duas funções como estas:

trim :: String -> Stringnormalize :: String -> String

Criamos duas funções compatíveis para a composição, uma vez que a entrada de uma corresponda ao tipo do outro. Eles também são comutativos, porque se eu correr guarnição e, em seguida, normalizar, obtenho o mesmo resultado como se eu corri primeiro “normalizar” e depois “guarnição”. Vamos ver a implementação.

Vale, o exemplo é muito bobo, mas é importante que nos tornemos conscientes do futuro. Teremos mais problemas no JavaScript com o número de parâmetros que podem permitir uma função.

O Arity and Tuples

Sabemos por Arity no número de parâmetros de entrada que aceitam uma função . É comum indicar isso como um comprimento de uma função.

A aridade de uma função pode fazer uma vitória de função na complexidade. Que uma função aceita vários parâmetros faz com que todos os argumentos tenham que ser calculados primeiro, isso os faz perder versatilidade.

Além disso, pode ser o caso que a complexidade interna de uma função é maior (que é grande aridade Nem sempre se comporta maior complexidade, pode simplesmente ser um sintoma disso).

Ter armas elevadas Além disso, faz-nos ter funções menos flexíveis. As funções com um parâmetro (ou UNARIES) são geralmente mais flexíveis porque, em geral, elas têm apenas uma única responsabilidade, realizam algum tipo de operação ou calculam no parâmetro de entrada e retornam o resultado.

Infelizmente, Na vida real, é complicado encontrar apenas UNÁLIO. No entanto, podemos fazer uma função retornar uma tupla, desta forma a próxima função seria um unharry e eu já teria todo o estado que você precisa.

A Tupla é uma lista finita e ordenada de valores Que são representados da seguinte forma (A, B, C). Tuples são um pacote de valores imutáveis, que têm um relacionamento e que podem ser usados para retornar vários valores para outras funções.

Podemos simular esse comportamento com um objeto JSON ou com objetos de matriz, assim Como vemos então com as tuplas, temos mais vantagens:

  • são imutáveis.
  • Evite a criação de novos tipos. Muitas vezes para criar classes para um único uso específico pode ser bastante barato para o desenvolvedor.
  • Evite criar matrizes heterogêneas: Trabalhar com essas matrizes heterogêneas supõe um monte de desenvolvimento de verificações de tipo. Matrizes é melhor basta usá-los quando se trabalha com coleções de objetos com o mesmo tipo.

o problema que temos, é que, embora os tupes fiquem um elemento na maioria das linguagens de programação funcional como Scala, em Javascript Não há nada que suporte as tuplas. A melhor opção para isso é que acreditamos que uma pequena livraria que suporta tuplas. A opção que Luis Atenção propõe em seu livro é esta:

const Tuple = function () { const typeInfo = Array.prototype.slice.call(arguments, 0); const _T = function () { const values = Array.prototype.slice.call(arguments, 0); if (values.some((val) => val === null || val === undefined) { throw new ReferenceError('Tuples may not have any null values'); } if (values.length !== typeInfo.length) { throw new TypeErro('Tuple arity does not match its prototype'); } values.map(function (val, index) { this = checkType(typeInfo)(val); }, this); Object.freeze(this); }; _T.prototype.values = function () { return Object.keys(this).map(function (k) { return this; } } return _T;}

uf, sim, muito chicha para cortar. Se percebermos que é uma função de tupla que retornará uma aula. A função serve para que possamos indicar o tamanho e os tipos dos elementos do TUPLA. Portanto, podemos fazer isso, por exemplo:

‘status’ é uma aula. Se você te der tuble, ele está retornando _t. Por meio de um clouser, uma classe pré-configurada é devolvida com o que precisamos. Mágico. Agora podemos definir uma nova tupla desta forma:

const status = new Status(401, 'No Authorize');

Quando instanciamos ‘status’, ele verifica se os valores nulos não estão acontecendo e O tamanho da tupla criada corresponde ao tamanho da TUPLA predefinida. Também verifica se o tipo que aconteceu é esperado.

Finalmente, ele tem um método para que possamos obter os valores no formato de matriz.É muito útil porque se usarmos a destruição novamente, podemos obter os valores da tupi desta maneira:

const = status.values();

bom … eles Não são os mais confortáveis do mundo tuplas em JavaScript, mas temos maneiras de simulá-lo. E se não tivéssemos que simulá-los? E se JS e serialmente trouxe-os? Bem, novamente, o datilogravura nos ajuda nisso. Eu poderia fazer isso:

let status: ; status = ; // OK status = ; // Error

Muito melhor :). Repito, continuo em mente, veio para ficar.

tuplas são um bom mecanismo para evitar a parada de funções. No entanto, há outro método chamado curricy, que não só nos ajudará com a aridade, mas é um bom mecanismo para melhorar a modularidade e a reutilização, mas … acho que vamos deixar aqui para hoje 🙂

Conclusão

Entendendo os tubos e suas formas de usá-los, nos ajudará a desenvolver código mais legível. Continuaremos falando sobre técnicas necessárias para cobrir todos os conceitos presentes nos tubos.

Por enquanto, acho que é um bom passo sabendo que as funções de design para que elas tenham uma aridade reduzida e Tipos dos parâmetros de entrada e saída de nossas funções, nos ajudaremos a fazer um código muito mais modernizável, modularizável e reutilizável.

Nós lemos 🙂

pd: Eu deixo o conceitual Mapa desta entrada:

thips-en-javascript

Anterior JavaScript Functional Programming Posts:

Introdução

  1. programação funcional em JavaScript
  2. programação funcional em JavaScript: os objetos
  3. funcional Programação em JavaScript: Funções

Controle de Fluxo Funcional

  1. Programação Funcional em JavaScript: Métodos Funcionais
  2. Programação Funcional em JavaScript: O Recursão

modularidade funcional

  1. programação funcional em JavaScript: Arity and Tuples
  2. Programação funcional em JavaScript: o currículo

imagem de capa | Flickr

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *