A tecnologia front-end, especialmente o JavaScript, tem sido historicamente desprezada por veteranos de retaguarda por não ser uma linguagem adequada. Principalmente porque o JavaScript começou como uma linguagem baseada em função – tornando-a imatura nas formas de crescimento potencial e no que ela pode fazer.
Eu me lembro do final dos anos 90 e início dos anos 2000, quando o JavaScript era usado principalmente para tornar as páginas HTML um pouco mais dinâmicas. Às vezes, colocaria alguns recursos visuais aqui e ali.
Atualmente, existem frameworks completos, bibliotecas e até sistemas de back-end rodando em JavaScript. Criar um aplicativo nativo para dispositivos móveis e desktop com JavaScript era inédito – mas hoje em dia, é tão comum, se não mais popular, do que o próprio Java – completo com suporte a várias plataformas.
JavaScript está em todo lugar. É fácil sujar as mãos com JavaScript e fazer algo útil com isso. Mas com facilidade vem possíveis problemas a longo prazo. Muitos programadores de JavaScript não são treinados nas formas de programação orientada a objetos. Não é culpa deles, não realmente. Às vezes, apenas nos envolvemos na tentativa de fazer as coisas funcionarem. Às vezes, simplesmente não sabemos o que não sabemos.
O que é programação orientada a objetos?
A programação orientada a objetos é baseada em uma mentalidade diferente. A idéia por trás disso é que você cria um plano para o seu ‘objeto’ e chama isso repetidamente para fazer o que quiser com ele.
Cada vez que você quiser usar um objeto, você precisa criá-lo primeiro para que ele exista e, em seguida, defina suas propriedades para usar as funcionalidades anexadas a ele. Essas funcionalidades são conhecidas como ‘métodos’.
Por exemplo, um objeto de pedido do cliente pode ter uma funcionalidade de detalhes do pedido de obtenção (método aka) anexada a ele.
Em uma estrutura baseada em funções, você precisará injetar uma dependência na função para fazê-la funcionar. Talvez você precise descobrir qual é o ID da ordem e injetá-lo na função.
O problema com o anterior é que, se você expandir o número de funções, isso pode ficar bastante confuso. Embora pareça inicialmente muito mais fácil apenas escrever tudo como funções e chamá-lo conforme necessário, a falta de definição do escopo pode levar a um efeito de encadeamento que afeta um número de relacionamentos desconhecidos, mas conectados. Classes, no entanto, impedem isso.
O construtor é o local onde as variáveis são definidas. Os métodos getter e setter são pontos de entrada na classe que faz alguma coisa. Quais funções são usadas e como elas são usadas estão ocultas. Cada vez que um novo objeto é criado, toda a classe e seus métodos são ‘clonados’ e se tornam acessíveis a esse item específico. O escopo da mudança é definido e sabemos que qualquer alteração em uma classe e seus métodos será uniformizada.
Quando codificamos com um monte de funções soltas, seu escopo de mudança não é frequentemente definido. A injeção de dependência é necessária para fazer a função funcionar e uma função geralmente requer outra função para funcionar. No valor nominal, a programação baseada em funções pode parecer fácil no começo, mas a longo prazo, é um pesadelo lógico a ser mantido.
Com a programação orientada a objetos, você só precisa chamar os métodos getter e setter para acessar a caixa preta da funcionalidade. Como consumidor da classe, você não precisa saber como funciona. Você só precisa saber que isso funciona.
Por que precisamos implementar a POO em JavaScript?
Código espaguete surge quando há muitas coisas interconectadas entre si. A programação baseada em funções, que é o que o JavaScript é inicialmente, pode ser rápida para codificar, mas, a longo prazo, cria um alto nível de risco e vários pontos de falha para o aplicativo final.
À medida que a base de código cresce, você precisará mudar a maneira de organizar seus pensamentos e começar a pensar em termos de objetos. O escopo dos objetos é mais fácil de entender e rastrear mentalmente do que uma série de funções interconectadas que são ligadas por meio de uma série de injeções de dependência.
O problema com a programação baseada em funções é que uma quebra na cadeia pode resultar na falha de todo o fluxo. Com objetos, um método quebrado não afeta (e não deve) o resto da classe.
Quando você baseia seu raciocínio em classes, em vez de em uma série de funções interconectadas, você está reduzindo o risco e o escopo de falhas, caso surja. Isso porque cada injeção de dependência cria um potencial ponto de falha. Não é apenas um custo de tempo para rastrear uma série de funções, é um tempo ainda maior e um custo mental se você tiver que fazer uma dúzia de vezes para exatamente a mesma coisa.
Palavras finais
Muitas vezes penso em programação orientada a objetos como a decisão ativa de conter e delimitar o escopo do que quer que eu esteja trabalhando. Angular requer uma compreensão geral do framework para implementar o OOP – algo que eu acho que precisarei fazer em um post completamente separado no futuro.
No geral, a POO em JavaScript pode diminuir a carga mental e os potenciais spaghetti, como os relacionamentos inerentes à programação baseada em funções. Embora possa ter funcionado algumas décadas atrás e em aplicativos de responsabilidade muito pequenos e únicos, os backends front-end e baseados em JavaScript aumentaram tanto em tamanho quanto em complexidade.
No final do dia, todo o código é o mesmo – apenas estruturado de forma diferente. O paradigma Orientado a Objetos foi pensado como uma solução para programação baseada em funções nuas – que requeria muito mais carga mental para descobrir do que uma estrutura baseada em classes. Quando a estrutura do código é facilmente compreensível e rastreável, reduz a chance de erros, facilitando a adição de novos recursos sem quebrar todo o resto.