Pare de discutir sobre programação funcional e POO

O post contém uma certa quantidade de brincadeiras, o Ministério da Saúde pede convincentemente a um leitor despreparado que se abstenha de ler.

Os artigos sobre o tópico "AF é melhor" ou "OOP é melhor" lembram um debate sobre o que é melhor para o almoço, um garfo ou uma colher. Tradicionalmente, os meses de junho começavam com uma colher, mas alguém com muita autoridade me disse uma vez que só come carne e usa um garfo, de modo que uma nova moda surgiu - coma com um garfo. Eles comem mingau e sopas, e até conseguem tomar batidos. A Internet está repleta de artigos, quão bons somos, que aprendemos a comer um smoothie com um garfo e superar todos os ancinhos. Isso é engraçado e triste, por um lado, dá uma vantagem competitiva para caras experientes que mostram super resultados simplesmente ignorando esse hype; por outro lado, eles precisam treinar colegas e funcionários, limpando o lixo causado pelo vento de suas cabeças. Neste artigo, tentarei contar minha visão, que não afirma ser verdade absoluta, mas funciona muito bem na prática

Como é habitual na ciência, começamos com definições. A definição clássica de POO envolve seguir os princípios de herança, encapsulamento e polimorfismo. Mas se não tivermos um desses componentes, será POO? E se não, o que será? Enquanto a parte chata da platéia pairava sobre esse assunto pouco prático e não nos dava nada, lembremos do que aconteceu antes da OLP . E diante dele havia programação processual. E a principal idéia do OOP naquele momento estava na conexão de dados e funções para o processamento deles . A idéia é simples, mas bastante revolucionária, é difícil imaginar quanto, mas mais sobre isso mais tarde.

A programação funcional, em uma interpretação livre, considera o programa como uma fórmula matemática . As fórmulas são bem formalizadas e com a mesma entrada retornam a mesma saída. Todo o programa consiste em rotinas que seguem os mesmos princípios. Como isso difere da mesma programação processual? O FP usa ativamente funções puras ; idealmente, todo o programa deve ser uma função pura. As funções puras não têm efeitos colaterais , elas podem ser facilmente memorizadas, testadas facilmente, etc. ... Podemos dizer que nas funções puras a principal idéia e vantagem do FP.

E agora duas perguntas:
- Podemos usar funções puras no OOP?
- Podemos vincular funções aos dados no FP?
A resposta para os dois é sim. Os métodos de classe estática podem ser puros, mesmo os métodos de instância podem ser considerados limpos se não criarem efeitos colaterais e considerarmos as propriedades da instância de classe como parâmetros. Os limites das definições clássicas são inflados e alguns podem discordar, mas na prática isso simplesmente funciona. E esses métodos são formalizados e testados não menos do que as funções puras clássicas escritas de acordo com todos os cânones. Sobre a ligação de métodos aos dados é um pouco mais complicado, a linguagem e as bibliotecas usadas impõem restrições. Digamos que em JavaScript isso seja feito elementarmente, não tenho certeza sobre Haskell e Erlang. Agora, o mais interessante é o que isso dá e por que o OOP já levantou tal hype há 20 a 30 anos. Se você escreve um pequeno programa - pode escrever como quiser, exceto pelo seu senso de beleza, que não afeta nada. Quando você cria um programa realmente grande, surge um problema de complexidade. Não é de complexidade computacional, acreditamos que aqui estamos fazendo tudo bem, mas de complexidade percebida. Digamos que você tenha 50.000 linhas de código e todas elas sejam úteis. Como organizá-los para não enlouquecer (ou não sair do trabalho às 11 noites)? Não podemos reduzir o número de operações, mas podemos reduzir o número de conexões entre elas (o encapsulamento nos ajuda nisso). Escondemos a implementação complexa por trás de uma interface simples e continuamos a trabalhar apenas com a interface. Por exemplo, a Internet é uma coisa terrivelmente complicada, mas a maioria dos desenvolvedores tem conhecimento suficiente do protocolo HTTP para fazer seu trabalho e deixar os níveis de rede, físico e outros para os administradores de sistema . Quanto mais fraca a conectividade dos nossos módulos, menor a complexidade no estágio de sua integração uns com os outros. Quanto menos um módulo conhece o outro, menos conectados eles são. Os métodos de vinculação aos dados dentro do módulo nos ajudam a livrar-se desse conhecimento dos consumidores do módulo. Essa é a principal vantagem pragmática do POO. Sobre o que? Abordagem acima sem vinculação de dados e métodos. A FP, como descobrimos, não diz nada sobre isso. Você pode passar classes como argumentos para funções puras, ou pode usar funções puras como métodos de uma classe, não se contradizem, mas apenas as complementam.

Na prática, onde principalmente uma abordagem funciona e onde está a outra principalmente? Quando escrevo um back - end no NodeJS, ele de alguma forma resulta em um paradigma funcional por si só. Porque Como a solicitação ao servidor é, por natureza, uma função, com entrada e saída fixas. A abordagem funcional se baseia nas solicitações do servidor muito naturalmente e o código é mais compacto e flexível. Quando crio um front - end para o navegador, o OOP geralmente funciona melhor, porque além da entrada e da saída, também temos um fluxo de eventos do usuário , além de eventos do programa, como o início e o fim das animações, solicitações do servidor, etc. ... A abordagem funcional funcionou se fosse apenas para desenhar uma página estática sem interatividade, ao usar o FP no front-end, o tempo interativo ou de desenvolvimento sofre (de acordo com nossas medidas, a cada 3 vezes). Porque

Qualquer paradigma de programação é baseado em um determinado modelo de realidade, e um modelo é sempre uma simplificação. No FP, o modelo impõe mais restrições ao mundo, tornando mais fácil a formalização. Pelo mesmo motivo, quando se torna irrelevante para as condições do problema, começa a exigir mais muletas. Por exemplo, os FIs de front-end resolveram o problema da entrada do usuário criando uma matriz de eventos (ações, redux oi). Mas essa é uma abstração irrelevante, que, além de seu impacto no desempenho, aumenta muito o tempo de desenvolvimento. Com essa abordagem, você pode criar uma lista de tarefas, mas em projetos muito grandes, é necessário quebrar tijolos com a testa e, em seguida, escrever artigos vitoriosos para os mesmos infelizes. Para comparação, quando escrevemos o terminal de troca (no vanilla js, é claro) com canvas, svg e atualizamos várias vezes por segundo via websockets, em alguns componentes atualizados com freqüência não excluímos divs, mas os reutilizamos, pois recriá-los é relativamente caro operação no navegador (e isso é importante se você tiver um aplicativo muito grande ). Se você programar no front-end, nem terá esse pensamento, pois já aceitou a imutabilidade (a propósito, isso é uma coisa maravilhosa para trabalhar com multithreading, o que não acontece no JS), para que cada ação passe por todos os redutores e outro lixo. Por outro lado, no backend muitas vezes acaba sem aulas, uma vez que, aliás, é possível evitar o custo de criá-las, pois as condições das tarefas são muito relevantes para o modelo FP. Mas, na maioria das vezes, os desenvolvedores de Java e PHP não têm pressa em estudar o FP, os fornecedores front-end estão na vanguarda, que realmente precisam menos. Como um exercício para a mente - é claro que é interessante, apenas os programas são obtidos g ... mas, e outra pessoa para usá-los. Apesar do fato de o front-end ser uma seção relativamente jovem de TI e de suas tarefas não resolvidas por várias gerações. O que, ao que parece, não é um exercício para a mente?