Por que saber de arquitetura de sistemas?

Fala devs!

Esses dias li na timeline de um desenvolvedor senior, ironizando, dizendo que em entrevistas de emprego ele pergunta aos candidatos se javascript é orientado à objetos. Já repudio de cara que alguém experiente esnobe quem quer que seja, mas enfim, vamos ao que importa.

E bora considerar o lado construtivo disso.

Orientação à objeto não deve ser associado diretamente à uma linguagem e, para já matar a curiosidade, é possível sim aplicar orientação à objetos no javascript. Não é a idéia aqui nesse post mostrarmos como aplicar POO (Programação Orientada à Objetos) no javascript, mas sim o conceito, que vai muito associado à arquitetura de sistemas.

Para quem desenvolve em java ou .NET, talvez isso seja mais visível, mas POO tem ligação com reaproveitamento de classes, herança, camadas como usamos por exemplo em DDD (Domain-Driven Design), entre outros pontos. Mas o que isso significa na prática?

Classes com construtores, que nos possibilitam instanciá-las como objetos, como por exemplo popularmos uma model. Isso torna-se um objeto em memória e que podemos trafegá-la entre as demais classes dos nossos sistemas, onde cada camada fará uso de acordo com a sua função. Confuso? Vamos a um exemplo para facilitar.

Imagine que você desenvolveu uma loja virtual, composta de clientes, produtos, pedidos (podem haver vários outros objetos, mas vamos simplificar nestes). Um pedido é composto de produtos e são realizados por um cliente, certo? Pois bem, quando a venda é realizada na sua loja virtual, recebemos informações que vão considerar estes 3 objetos. O pedido deve te informar qual objeto cliente é dono dele, assim como o pedido deve também detalhar quais produtos (uma lista de objetos) compõem aquela compra. Até aqui ok?

Bom, pensando que receberemos então um objeto que vai gerar o pedido, que contém um objeto cliente e uma lista de objetos, os produtos, vamos para dentro do sistema. Usaremos como exemplo uma API de pedidos que recebe essa compra, nela a requisição de entrada é composta pela identificação do cliente e quais produtos ele colocou no seu carrinho de compra. Essa junção de informações vai compôr o pedido, além de algumas outras, como o endereço de entrega. Quando seu sistema recebe as informações, sua camada de negócios valida o cliente e os produtos. Estando ok, o objeto é enviado para a camada de dados, que gravará as informações no seu banco de dados e te devolverá algo importante para o processo: o número do pedido ou compra. Temos o objeto “pedido”. Sua camada de dados devolve para a camada de negócios e esta, após validar, devolve para a camada de apresentação, ou seja, informa ao cliente o número do pedido. Estamos sendo bem simplistas aqui, a API apenas devolve a informação, o frontend de fato apresenta, mas notem que os objetos que nos permitem criar um pedido estão trafegando entre todas as camadas.

O assunto é mais amplo que isso, contemplam heranças, quando se herda uma classe para complementar sua implementação, ou quando usamos interfaces para garantirmos que nossas classes sigam padrões quando formos implementadá-las, enfim. É importante que todos busquem cursos de arquitetura de sistemas para formar esse conhecimento com mais riqueza.

E se alguém te perguntar se javascript é orientado à objetos, seja direto, não é a linguagem que te faz desenvolver em POO. Você usa a linguagem da forma que quiser, inclusive aplicando POO. Há linguagens que isso pode ser mais natural, outras não, mas novamente, aplicar o conceito de POO é que é a chave da idéia aqui.

Para quem quiser saber mais sobre POO em javascript, segue link interessante da Alura: https://www.alura.com.br/conteudo/javascritpt-orientacao-objetos

Bora codar, galera!

Até a próxima.