Forem: Lucas Mateus

Design: Dificuldades e Carreira

Lucas Mateus — Mon, 22 May 2023 11:59:13 +0000

Olá! Hoje vamos ver um pouco sobre design, especialmente sobre as dificuldades e carreira. Se liga no que você vai ver aqui:

Sumário

1. Introdução
- 1.1 O que é design?
2. Design é complicado!
- 2.1 Networking
- 2.2 Clientes
- 2.3 Conciliação
- 2.4 Bloqueio Criativo
3. Segmentos de design
4. Conclusão

Espero que você goste do conteúdo, não se esqueça de deixar sua reação e seu comentário. Boa leitura :)

1. Introdução

Se você, assim como eu, gosta de design, já deve ter considerado seguir carreira nessa área. Mas já parou para refletir sobre como é o dia a dia nesse campo, quais ramos seguir em design e quais dificuldades poderá enfrentar? Neste post, vou apresentar um pouco do universo do design. E para isso, convidei dois designers de diferentes segmentos para me auxiliarem a fornecer informações valiosas.

Então vamos nessa!

1.1 O que é design?

Creio que essa seja uma das perguntas mais desafiadoras de responder para a maioria dos designers, pois cada um possui sua própria concepção do que é design.

Com isso você pode se perguntar: "Design não é arte?".

Segundo Jezreel, o design não é arte; ele não flui da mesma forma que a arte. O design envolve a concepção de algo com o propósito de sua execução concreta. Essa perspectiva é semelhante à visão de Steve Jobs.

Design é solução. Todo designer pode afirmar que isso é um fato. Embora essa seja uma definição simplificada do vasto universo do design, na prática, o design é exatamente isso: encontrar soluções para problemas e necessidades por meio do planejamento e da criação de produtos, serviços, interfaces e experiências.

Há profissionais que aderem mais ao conceito visual do design. Nesse caso, você pode se perguntar: "Qual é a justificativa para esse ponto de vista?". Alguns argumentam que o design é voltado para criar soluções esteticamente agradáveis, de acordo com a visão concreta e abstrata do cliente. Essa abordagem enfatiza a importância da estética e da percepção visual na comunicação e na experiência do usuário.

2. Design é complicado!

Algumas vezes, quando se é iniciante, é comum sentir dificuldade em realizar determinadas tarefas no design. Isso pode ser devido à falta de conhecimento sobre as ferramentas utilizadas, falta de domínio dos conceitos envolvidos e outras questões. É importante ressaltar que até mesmo profissionais experientes passaram por situações semelhantes em suas trajetórias de trabalho. O aprendizado e a evolução no design são processos contínuos, e é natural enfrentar desafios ao longo do caminho. O importante é persistir, buscar conhecimento e experiência para superar essas dificuldades.

No início de sua carreira, Rômulo enfrentou dificuldades ao tentar encontrar recursos de aprendizado. Embora haja uma quantidade considerável de conteúdo disponível, pode ser desafiador saber por onde começar. Por essa razão, é interessante buscar referências de profissionais renomados, como Ryan Dutra, Leandro Rezende, Marcelo Kimura e muitos outros designers que estão disponíveis em plataformas como o Instagram. Seguir essas referências pode ajudar a encontrar inspiração, aprender novas técnicas e obter insights valiosos para o desenvolvimento no campo do design.

Ao buscar referências, torna-se mais fácil ter uma direção para os estudos. No entanto, caso isso não seja suficiente, é recomendado procurar comunidades de design online. Para fornecer algumas opções de comunidades, aqui estão algumas sugestões:

Brasil Design
Comunidade XLab
Comunidade Teu Designer

Essas comunidades podem oferecer um espaço para interação com outros designers, compartilhamento de conhecimento e discussões relevantes sobre o campo do design.

(comenta mais comunidades aí)

Além de fornecer uma direção sobre como e o que estudar, buscar referências e se envolver em comunidades de design, é essencial desenvolver uma rede de contatos profissionais, conhecido como networking. O networking é um pré-requisito para se tornar um designer profissional.

2.1 Networking

Vivemos em uma era em que a comunicação é fundamental para o progresso. Ter uma rede de contatos profissionais é essencial para estabelecer uma relação de mutualismo, na qual ambas as partes se beneficiam. É importante ter em mente que, para aumentar sua produtividade, você depende da colaboração de outras pessoas.

"Ah, mas por que o networking é obrigatório? Sou uma pessoa tímida!"

Quando você está começando no mercado, a primeira pergunta a ser feita é: "Quem é você?" Não há prova de conceito melhor do que receber elogios e reconhecimento pelo seu trabalho, pois isso gera valor tanto interna quanto externamente. E sobre a Timidez, não tem pra onde correr, tem que ser sem vergonha kkkk. Na área de design, a comunicação interpessoal é essencial, principalmente ao lidar com clientes.

Por falar em clientes...

2.2 Clientes

Se tem alguém que retira a paciência de qualquer designer, esse alguém o cliente. Muitas das vezes, eles exigem coisas sem nexo para o negócio.

Jezreel ainda complementa com uma experiência vivida no trabalho em que o cliente exigiu uma arte bastante complexa, incluindo a inserção de mais de vinte serviços da empresa, os contatos e o endereço, tanto na frente quanto no verso de um cartão de visita com dimensões de 9 cm de largura por 4 cm de altura.

Vida de designer realmente pode ser desafiadora em alguns momentos. É verdade que, muitas vezes, é necessário - permita-me falar o clichê - sair da zona de conforto para atender às demandas dos clientes e alcançar resultados satisfatórios. A versatilidade e o conhecimento de diversas ferramentas e softwares são essenciais nessa profissão.

O Cliente nem sempre tem a razão absoluta. Embora seja necessário levar em consideração as demandas e expectativas dos clientes, também é fundamental exercer sua expertise e julgamento profissional para oferecer soluções eficazes e criativas.

2.3 Conciliação

A vida não é só trabalho!

Para algumas pessoas pode ser normal gostar do trabalho, o que é ok, mas evite transformar sua vida em somente trabalho. A vida é mais do que isso, há tantas coisas que você não fez e experimentou que você poderia dá uma chance no seu tempo vago, no lugar de pensar apenas em trabalho.

Em conversas com designers, percebi que muitos profissionais que atuam ou já atuaram em agências de design enfrentam dificuldades para conciliar o trabalho com a vida pessoal devido à alta demanda.

Saiba conciliar e definir prioridades de elaboração para maior efetividade.

2.4 Bloqueio criativo

Aqui eu gostaria de abrir um parêntese para um breve desabafo, pois sei que muitas pessoas enfrentam bloqueio criativo, e eu mesmo estou passando por isso neste exato momento em que escrevo este post. É uma situação difícil, que gera uma grande frustração e uma ansiedade angustiante. Se isso acontece comigo, que não estou sob uma pressão intensa de uma agência com alta demanda, imagine para um designer profissional. É importante lembrar que os designers também são seres humanos e precisam de cuidados mentais e físicos para manter seu corpo funcionando com produtividade. Procure um psicólogo, um dentista, um nutricionista, um profissional de saúde. Cuide-se!!

Agora voltando para a linha que eu estava seguindo...

O bloqueio criativo é algo comum de ocorrer no início da carreira, pois a criatividade é como um músculo que se fortalece com o tempo, conforme afirmou Jezreel.

Não há para onde correr, para exercitar a criatividade é necessário começar a esboçar. Mesmo que sejam apenas rabiscos aleatórios kkkk. Em suma, busque fazer o inesperado ao esboçar, pois o esperado pode ser planejado quando sua criatividade estiver em pleno exercício.

3. Segmentos de design

Se em algum momento você já se questionou sobre quais áreas do design seguir, este é o momento de se encantar.

A área do design é extremamente ampla e se você pensou que se limita apenas ao web design ou social media, está enganado(a) e é um equívoco bastante comum.

Em uma pesquisa que conduzi com pessoas comuns do meu círculo social, perguntei quais áreas do design elas conheciam e as respostas geralmente se limitavam a apenas quatro: design de moda, design de interiores, design de produto e design gráfico (não necessariamente nessa ordem).

Depois de perceber isso, eu fiquei mais curioso e fui pesquisar quais são os segmentos mais conhecidos - baseado em pesquisa renomada que não seja a minha kkkk - e bem remunerados no campo do design.

Vamos lá...

De acordo com a UniFOA, as 7 principais áreas de atuação do design são:

Design de Moda;
Design Gráfico;
Design de Produto;
Design de Serviços;
Design de Interiores;
Design de Mobiliário;
Design de Animação.

Mas calma lá...

Cada uma dessas áreas possui subdivisões interessantes, como o social media design, UI design e até mesmo o UX design. Além disso, percebo um crescimento promissor na área de HX (Human Experience), que está começando a ganhar destaque.

Agora vamos para salários em alguns segmentos dos segmentos kkkk.

Antes que você me pergunte sobre a fonte, baseei-me nas médias salariais do Glassdoor, LoveMondays e Catho. No entanto, é importante ressaltar que esses valores podem variar de acordo com a região.

Quanto ao gráfico, vale ressaltar que segmentos como o UX são bastante atrativos para o público. O UX é amplamente utilizado no desenvolvimento de soluções web no cotidiano, embora vá muito além disso.

4. Conclusão

Neste post, abordamos algumas das dificuldades enfrentadas pelos designers, falamos sobre salários, segmentos e a importância de ter cuidado no trabalho. Espero que você tenha gostado e, se ainda estiver indeciso sobre seguir carreira nessa área, sugiro que tenha calma, faça mais pesquisas e se apaixone ainda mais pelo design antes de tomar uma decisão. Se sua motivação principal for apenas dinheiro e não paixão, sugiro que entre com cautela, mantendo a calma e focando sempre nos fundamentos das coisas.

É isso! Espero que você que tenha chegado até aqui tenha gostado :)

Participação:
Rômulo Henrique: Web Designer independente;
Jezreel Lucas: Social Media Designer.

Protocolo HTTP

Lucas Mateus — Sat, 29 Apr 2023 20:16:55 +0000

Olá! Hoje vamos ver um pouco sobre o protocolo HTTP, saber o que é isto, como ele funciona etc., se liga no sumário:

Sumário

1. Introdução
- 1.1 O que é um protocolo
2. Como isso funciona?
- 2.1 Estrutura
- 2.2 Como sua requisição http chega no servidor?
3. Versionamento
- 3.1 Custos
4. Vantagens e Desvantagens
5. Conclusão

Espero que você goste do conteúdo e não se esqueça de fornecer seu feedback para que eu possa melhorar cada vez mais.

1. Introdução

Certo dia eu estava estudando sobre o Netty, um framework de servidor com infraestrutura assíncrona e não bloqueante. Aí me veio a ideia de escrever sobre o protocolo HTTP e aqui está ela se tornando realidade. Vamos lá!

Você, assim como eu, deve usar a internet com certa regularidade e realizar pesquisas no Bing, Google ou qualquer que seja seu mecanismo de busca primário. Entretanto, em algum momento, você já se perguntou como suas pesquisas são trazidas até você?

De forma resumida funciona assim:

Você abre o seu navegador e digita a pesquisa que deseja. Em seguida, você executa a ação de pesquisar. Essa ação solicita o que você pediu para um servidor que pode estar em qualquer lugar deste mundo. Então, o servidor processa o seu pedido e retorna a página de pesquisa com vários links.

Creio que você tenha entendido esse ponto, mas vamos nos aprofundar um pouco mais.

Para que a solicitação e a resposta aconteçam, é utilizado um protocolo de comunicação, seja o HTTP, SSH, FTP, etc. Mas como este post é sobre HTTP, vamos falar exclusivamente dele. (Se você quiser um post comparando esses protocolos, comenta aí).

1.1 O que é um protocolo

Se você não sabe o que é um protocolo, provavelmente deve ter ficado assim neste ultimo parágrafo:

Vamos com calma. Basicamente, um protocolo é um conjunto de regras e procedimentos padronizados que são seguidos para permitir a comunicação entre dispositivos ou sistemas de computação.

"Ainda não entendi!" Vou te dar um exemplo prático.

Imagine que você quer encontrar uma resposta para uma pergunta que tem na sua cabeça e decide buscar no Google. Nesse exemplo, você é o cliente e o Google é o servidor.

Para que a sua pergunta chegue ao Google e retorne a resposta correta, é preciso que ambos usem um conjunto de regras e procedimentos que permitam a comunicação entre eles. Essas regras e procedimentos são chamados de protocolo.

O protocolo define como o cliente deve fazer a sua solicitação (nesse caso, uma pesquisa) e como o servidor deve responder a essa solicitação. É como se fosse uma linguagem que ambos precisam falar para se entenderem.

No caso do Google, o protocolo utilizado é o HTTP (Hypertext Transfer Protocol), que é um conjunto de regras para transferência de informações na internet. Quando você faz uma pesquisa no Google, o seu navegador web envia uma requisição HTTP para o servidor do Google, pedindo a informação desejada. O servidor então responde com uma mensagem HTTP contendo a resposta da pesquisa. Tudo isso acontece seguindo o protocolo definido pelo HTTP.

2. Como funciona o HTTP?

Se você prestou atenção na thumbnail, deve ter percebido que é exatamente esta pergunta agora, e isso não foi coincidência. Bom, é um pouquinho complicado explicar como funciona o HTTP, porque eu preciso entrar em mais detalhes, mas vamos lá.

2.1 Estrutura

Antes de você entender os processos, creio que seja relevante saber como é a estrutura desse negócio. Então vamos lá.

O HTTP possui duas formas estruturais para mensagens, são elas: formato de mensagem de solicitação e o formato de mensagem de resposta, conforme a imagem abaixo:

"O que raios são cada uma dessas camadas aí?", segue o fio:

Linha de solicitação: é o local onde está definido o tipo de solicitação (GET, POST, PUT etc.), a URL (http://www.google.com) e a versão do HTTP (1.1 ou 2.0). Exemplo:

Linha de status: é o local onde o servidor retorna se a solicitação foi atendida com êxito ou não. Nesta linha está contida a versão do http, o código de status (200, 404, 500 etc.) e frase de status (OK, Not Found, Internal Server Error etc.). Exemplo:

Cabeçalho: é um conjunto de informações que são enviadas junto com a solicitação ou resposta HTTP para fornecer informações adicionais sobre a transação. Ele contém metadados que descrevem vários aspectos da solicitação ou resposta, como a versão do protocolo, os tipos de dados aceitos, as informações de autenticação, o tamanho do conteúdo, entre outros. O cabeçalho é dividido em duas seções: o cabeçalho da solicitação e o cabeçalho da resposta. Ambos contêm campos de cabeçalho específicos que são definidos pelo protocolo HTTP.

Exemplo de cabeçalho de solicitação informando quem tá solicitando a requisição:

User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0)

Exemplo de cabeçalho de resposta do servidor informando o tipo de conteúdo que está sendo retornado na resposta:

content-type: text/javascript

Linha em branco: não tem o que dizer, é uma linha em branco kkkkk.

"Há, mas por que tem que ter uma linha em branco?" - Bom, ela é necessária para separar as informações de cabeçalho dos dados propriamente ditos. Isso permite que o receptor da mensagem saiba onde termina o cabeçalho e começa o corpo da mensagem. A falta dessa linha em branco pode levar a erros de interpretação do conteúdo da mensagem.

Corpo: pode estar presente em uma mensagem de solicitação ou de resposta. Normalmente contém o documento a ser transmitido ou recebido.

Exemplo de um corpo de solicitação referente a um formulário de cadastro simples:

nome=João Silva&email=joao.silva@exemplo.com&senha=abc123

Exemplo de um corpo de resposta referente a uma pesquisa simples de um site que retorna uma documento HTML contendo os links de resultado:

<html>
<head>
    <title>Resultados da pesquisa</title>
</head>
<body>
    <h1>Resultados da pesquisa</h1>
    <ul>
        <li><a href="https://www.example.com">Exemplo</a></li>
        <li><a href="https://www.google.com">Google</a></li>
        <li><a href="https://pt.wikipedia.org">Wikipédia</a></li>
    </ul>
</body>
</html>

Show!! Agora que você viu como é composta a requisição HTTP e a resposta, nada melhor do que um exemplo completo, não é mesmo? Vamos lá.

Exemplo de uma pesquisa no bing:

solicitação http

GET /search?q=Lucas+Jdev HTTP/1.1
Host: www.bing.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Connection: keep-alive
Referer: https://www.bing.com/

resposta http

HTTP/1.1 200 OK
Date: Tue, 26 Apr 2023 10:30:00 GMT
Server: Microsoft-IIS/10.0
Content-Type: text/html; charset=utf-8
Content-Length: 298

<script type="text/javascript">//<![CDATA[
sj_evt && sj_evt.bind( "onRALoad", function() { var reportActivityModule = new ModernRewards.ReportActivity({"AnimateHeader":true,"IsAuthenticated":true,"DashboardUrl":"https://rewards.bing.com/?signin=1","IsMobileClient":false,"RewardsIncrement":1,"RewardsSessionData":{"IsRewardUser":true,"IsLinkedUser":false,"IsTenantEnabled":false,"IsTrialUser":false,"TrialUserClaimBalance":-1.0,"IsRebatesUser":false,"IsRebatesDeniedUser":false,"Balance":129,"RewardsBalance":129,"GiveBalance":0,"RebatesBalance":0.0,"IsGiveModeOn":false,"GiveModeCid":"","GiveModeCName":"","PreviousBalance":129,"GoalTrackBalance":0,"IsLevel2":false,"IsOptOut":false,"IsSuspended":false,"ShowAnimation":true,"EPuid":"FQ3QSpOEsvC09O9NlYX5nfc-yXWgdu80h41sspLcTT_-rxCXzvfdivH5irtG3RtcZAEyiWMW5DolbOxJMGOt5w","IsRedirectedFromOldDashboard":false,"ImpressionLifeTimeCount":0,"DailyImpressionHPCount":0,"DailyImpressionSerpCount":1,"VisitedCount":8,"LastVisitTime":"2023-04-26T07:00:00Z","LastAutoOpenFlyoutTime":"0001-01-01T00:00:00","AutoOpenFlyoutFlag":false,"IsCLOUser":false,"Waitlist":"2","SERPTheme":""},"RewardsHeader":"Rewards","NeedUpdateRewardsHeaderLink":false,"AnimationAltText":"Animation","AutoOpenFlyout":false,"IsGiveHeaderTextEnabled":false,"IsGiveSerpHeaderTealHeartEnabled":false,"IsRewardsEntryPointEnabled":false,"IsRewardsEntryPointToggleEnabled":false,"BalanceMessage":null,"ShowNonMemberUpsellMessage":false,"LogWaitlistAutoJoin":false}); reportActivityModule.initialize(); }, 1 );;
//]]></script>

"O que diabos é isso no corpo da resposta???", calma, isso é apenas um script que o servidor está retornando, e o cliente o interpreta e executa na renderização.

Ufa! Finalmente podemos dizer que terminamos, pelo menos a base. Entretanto, vamos aprofundar ainda mais no HTTP.

2.2 Como sua requisição http chega no servidor?

No ecossistema da infraestrutura de redes, é comum se referir a modelos como o OSI e arquiteturas como o TCP/IP. Neste contexto, irei focar na arquitetura TCP/IP, já que ela é a mais amplamente utilizada na prática de redes de computadores baseadas em internet.

Basicamente, a web funciona da seguinte maneira:

Você faz uma pesquisa no Google sobre "capivaras fofas". Para que o seu navegador possa se comunicar perfeitamente com o servidor do Google, eles utilizam um protocolo, que é o HTTP. Esse protocolo funciona na camada de aplicação na rede.

Caso você ainda não tenha se perguntado como a entrega da solicitação e da resposta é garantida, não se preocupe. Vou explicar agora mesmo. Para garantir uma entrega ideal, a camada de aplicação delega para a camada abaixo o empacotamento da requisição em fragmentos, que são enviados para o servidor. Nessa camada é utilizado o protocolo TCP (Transmission Control Protocol) ou UDP (User Datagram Protocol).

"Ah, mas como essa camada faz isso?" Eu teria que fazer um post exclusivamente sobre esses protocolos, então comenta aí se você quer.

Ok, depois disso, a camada de transporte não sabe qual é o melhor caminho para esses pacotes chegarem até o servidor por meio da rede e é aí que entra a camada de rede. Nela ocorre a determinação dos melhores caminhos na rede por meio de protocolos de roteamento, como o BGP (Border Gateway Protocol). Além de definir o melhor caminho, esta camada também endereça todos os pacotes para dizer para onde vão.

Tudo suave até aqui, porém, a pergunta que não quer calar é: "Se a minha requisição de pesquisa foi feita na aplicação, a camada de transporte compactou minha requisição em pacotes de dados menores, a camada de rede cuidou da logística, então quem danado envia esse negócio?"

A resposta é simples: é a camada de enlace. Ela é responsável por trafegar os pacotes na rede física. "E como danado ela faz isso?" Bom, ela converte os dados dos pacotes de dados em sinais elétricos, ópticos ou de rádio que podem ser transmitidos pela rede física e vice-versa.

Ou seja, para passar na fibra óptica em que o servidor do Google está conectado, quem é responsável por isso é a camada de enlace.

3. Versionamento

Confesso que essa parte me deixou muito curioso e, para esclarecer minhas dúvidas, precisei consultar alguns profissionais da área. Então, sem mais delongas, vamos falar sobre o versionamento do protocolo HTTP.

HTTP/0.9 (1991): A primeira versão do HTTP, criada como um protocolo simples para transferência de documentos em redes de computadores. Possuía apenas um método (GET) e não continha cabeçalhos de requisição ou resposta.
HTTP/1.0 (1996): Versão que incluiu métodos adicionais (POST, PUT, DELETE) e suporte para cabeçalhos de requisição e resposta. Porém, cada conexão só podia enviar uma única requisição e resposta, o que aumentava o tempo de resposta.
HTTP/1.1 (1999): Introduziu a capacidade de enviar várias requisições em uma única conexão (conexão persistente) e suporte a compressão de dados e autenticação. Também permitiu o uso de cabeçalhos de cache para melhorar o desempenho e reduzir a largura de banda.
HTTP/2 (2015): A principal mudança em relação ao HTTP/1.1 foi a implementação do multiplexação, permitindo que várias requisições e respostas sejam transmitidas simultaneamente em uma única conexão, além de suporte para criptografia TLS por padrão. Outras melhorias incluem o uso de cabeçalhos de compressão HPACK, priorização de requisições e o push de recursos do servidor para o cliente sem a necessidade de uma requisição prévia.
HTTP/3 (2020): Também conhecido como HTTP sobre QUIC, é a versão mais recente do protocolo. O HTTP/3 utiliza o protocolo de transporte QUIC, que foi desenvolvido pela Google para melhorar a velocidade de conexão em redes com perda de pacotes. Entre as principais vantagens do HTTP/3 estão a melhoria no tempo de resposta e a redução no tempo de carregamento das páginas em redes com alta latência.

3.1 Custos

Outra coisa interessante sobre versionamento são os custos. "Mas o que seriam esses custos? É em relação à performance? Ou é em relação ao valor do maquinário?", bom, o custo envolve o maquinário quando se trata de atualização e maquinário é dinheiro.

Para falar mais sobre isso, eu questionei um professor acadêmico da área de redes e um coordenador de TI - pelo menos até o momento - do IFRN.

Vamos lá para algumas perguntas:

Qual(is) o(s) custo(s) para atualizar um servidor legado (antigo) para utilizar um protocolo mais atual?

Creio que o "custo" seja superar alguns desafios, como a necessidade de atualização de infraestrutura e a compatibilidade com alguns servidores e navegadores mais antigos. É aquela história: eu vou lançar uma versão mais nova do protocolo, só que precisarei atualizar todo o meu parque tecnológico (ou dos meus clientes) e isto pode em algum momento gerar uma incompatibilidade: o cliente ficar sem acesso aos recursos temporariamente, etc..

César A. F. Azevedo - Professor de redes do IFRN-JC

Se a pessoa tiver um servidor legado (antigo), compensa fazer uma atualização em termo financeiro? (Pergunta adaptada).

Depende, a maioria dos servidores web que se usam por aí são software livre, não vai ter custo financeiro de atualizar, então nesse sentido compensaria. Mas update de um software geralmente aumenta/muda os requisitos das dependências e aí se você não pode atualizar uma dependência comum a outro serviço além do servidor http, isso se torna um problema.[...] Tem muita coisa que não necessariamente é relacionado ao protocolo que pode ser complicado para uma atualização. É bom sempre manter software atualizado, mas as vezes tem uns problemas que lhe impedem.

Rezembrim P. Soares - Coordenador de TI no IFRN-JC

Com isso podemos chegar a uma leve conclusão que pode ser que você tenha custos para atualização do protocolo em seu servidor HTTP, mas isso é algo a se ver com calma com a equipe de infraestrutura para saber se compensa em seu cenário.

4. Vantagens e Desvantagens

O HTTP é um protocolo com várias vantagens e desvantagens, afinal, nem tudo são flores.

As principais vantagens do http são:

Simplicidade: Protocolo de comunicação simples, que permite a transferência de informações de forma clara e direta entre o servidor e o cliente.
Amplamente utilizado: É um dos protocolos mais utilizados na Internet e é suportado por praticamente todos os navegadores e servidores.
Flexibilidade: Permite que diferentes tipos de conteúdo, como textos, imagens, vídeos e áudios, sejam transferidos na mesma conexão.
Caching: Suporta a técnica de cache, que permite que o cliente armazene em cache recursos que foram previamente baixados, reduzindo o tempo de carregamento da página.
Fácil depuração: Protocolo de texto simples, o que facilita a depuração de problemas em caso de falhas ou erros.

Desvantagens:

Falta de segurança: Não possui mecanismos de segurança integrados para proteger a comunicação entre o cliente e o servidor. Isso torna a comunicação vulnerável a ataques de interceptação, roubo de informações e invasão de privacidade.
Desempenho: Usa um modelo de solicitação-resposta, o que significa que uma solicitação é feita pelo cliente e uma resposta é enviada pelo servidor para cada recurso solicitado. Isso pode levar a atrasos de desempenho significativos, especialmente para sites com muitos recursos.
Limitações de cache: Usa cache do lado do cliente para melhorar o desempenho, mas o cache tem suas limitações. Por exemplo, os dados em cache podem se tornar obsoletos rapidamente, o que pode levar a resultados imprecisos ou desatualizados.
Limitações de conexão: É limitado pelo número de conexões que um servidor pode suportar simultaneamente. Isso pode levar a problemas de desempenho quando muitos clientes tentam acessar um site ao mesmo tempo.
Restrições de comunicação: É um protocolo de comunicação de texto simples, o que significa que ele é limitado a transmitir apenas dados de texto. Isso pode ser um problema quando se deseja transmitir outros tipos de dados, como imagens, vídeos ou áudio, que podem exigir outros protocolos para serem transmitidos eficientemente.

5. Conclusão

Creio que este post tenha sido útil para você de alguma forma, senão você não teria chegado até aqui. O protocolo visto neste post é muito mais denso do que eu apresentei aqui, então você pode se aprofundar mais no assunto caso queira.

Se não for pedir demais, compartilhe este post com seus colegas que estão estudando sobre o HTTP ou que vão estudar. Deixe sua reação e comenta se gostou do conteúdo, nos vemos em um próximo post.

Participação

Rezembrim de Paula Soares: Servidor público de TI no IFRN;
César Augusto de Freitas Azevedo: Professor de Infraestrutura de Redes no IFRN.

Referências

Network protocols
O que é um protocolo? | Definição de protocolo de rede
Communication protocol
FOROUZAN, B. A. Comunicação de dados e redes de computadores. 4. ed. Porto Alegre: AMGH Editora, 2014.
FOROUZAN, B. A. TCP/IP Protocol Suite. 4th ed. McGraw-Hill, 2013.
HTTP/2 vs HTTP/1.1
What is HTTP/3
O que é HTTP?

Quem é melhor? ORM ou SQL puro?

Lucas Mateus — Fri, 21 Apr 2023 21:12:41 +0000

Olá! Hoje vamos ver um pouco sobre o dilema de usar ORM ou SQL puro nos seus projetos. Nesse post vou abordar os seguintes pontos:

Sumário

1. Introdução
- 1.1 SQL Puro?
- 1.2 O que é ORM?
2. Performance
- 2.1 O famoso N+1
3. Produtividade
4. Escalabilidade
5. Conclusão

Espero que você goste e que principalmente te ajude no dia a dia, no mais é isso e boa leitura :)

OBS: Não se esqueça de fornecer seu feedback, isso me ajuda demais em criar novos conteúdos.

=================================================

1. Introdução

Se você já aprendeu a construir uma aplicação, nem que seja simples, provavelmente já ouviu falar de banco de dados. Por mais que você possa não saber o que é isso, eu vou te explicar de maneira superficial (coloca nos comentários se você quer um post especialmente sobre banco de dados).

"Banco de dados é um local é onde se guarda os dados de uma aplicação".

Lucas Jdev

Alguns bancos de dados são SQL (Structure Query Language) outros NoSql, mas vamos focar aqui nesse post em SQL, ok?

Ok, sabendo disso, há situações no dia a dia de desenvolvimento que pode causar um impasse em algumas pessoas, como por exemplo: "Desenvolver o banco e efetuar operações com SQL puro ou usar ORM?".

Caso você não saiba o que é ORM ou o que é SQL puro? fica frio e segue o fio.

1.1 SQL puro

Caso você não saiba o que é isso, basicamente é a linguagem de estilo funcional para bancos de dados relacionais, ou seja, com ela você informa para o banco o que fazer e não como fazer. Com ela conseguimos salvar os dados no banco, atualizar, deletar e efetuar até mesmo busca específicas sobre os dados.

SQL é extremamente importante para a vida de desenvolvedor, ora, se você nunca sofreu um pouquinho criando conexões e lidando com transações jdbc da vida, você ainda não viveu o suficiente kkkk, mas brincadeiras a parte, é muito interessante saber como utilizar ela pois ela é a base para entender ORM.

"O que raios é esse negócio de ORM que você tanto fala?", calma, segue o fio.

1.2 O que é ORM?

ORM é uma sigla para Object-Relational Mapping, ou seja, Mapeamento Objeto Relacional. ORM por si só é uma técnica de permite que as aplicações trabalhem com objetos em vez de lidar com tabelas sql por cima dos panos. Entretanto, geralmente quando falamos de ORM, estamos nos referindo a ferramentas de desenvolvimento, os famosos frameworks ORM.

Existem diversos frameworks ORM no mercado como o famoso Prisma, Elouquent, Hibernate etc. Ele é muito útil no dia a dia, pois possibilita padronizar e automatizar tarefas rotineiramente repetitivas no cotidiano de dev.

Agora que você já sabe superficialmente o que são ambos, tenha fixado na cabeça uma coisa "Nem tudo são flores". Usar SQL puro tem suas vantagens, muito boas por sinal, mas também não é um mar de rosas. A mesma ideia serve para ORM, pois há muitas vantagens como produtividade de desenvolvimento, entretanto, há algumas desvantagens no seu uso a depender do caso.

"Mas o que são essas vantagens e desvantagens na real? Dá pra fazer algum comparativo entre ambos?", neste post eu pretendo trazer 3 pontos que eu julguei interessantes para ser debatidos (caso discorde, comenta aí) são eles: Performance, produtividade e escalabilidade.

2. Performance

Sim, comecei por uma das partes mais polêmicas quando se trata de ORM. "Mas por quê?" Algumas pessoas afirmam que ORM é muito menos performático do que usar SQL puro. De fato, não há como negar que ter uma camada de abstração em uma infraestrutura como a camada de dados aumenta a latência, isso é inquestionável. Porém, entretanto e todavia, essa diferença de latência pode ser desprezível a depender do nível da tua aplicação.

"Calma, que raios de camada é essa que você falou?", segue o fio das imagens:

Na imagem acima você consegue ver como é o processo com SQL puro na sua aplicação. Resumindo, você terá um driver de conexão que permite a conexão direta com o banco de dados.

Já nesta imagem você consegue ver claramente que há uma camada a mais, camada essa que pode gerar um overhead adicional na aplicação, nossa camada de ORM, uma abstração a mais.

"Mas pera... em um caso hipotético que eu tenho uma aplicação de CRUD para uma padaria da minha vizinhança, qual é melhor? julgando unicamente Performance?", já que você está com teimosia, vamos julgar somente nesse critério. Bom... a resposta é que não faz diferença nesse caso kkkk. A latência só influencia mais em aplicações mais robustas que precisam mais do que um CRUD simples ou consultas simples.

"Ah Lucas, mas meu papel como desenvolvedor não é fazer o melhor software possível?", lembre-se que decisões não são tomadas levando somente um fator em consideração, deve ser levado em consideração a produtividade da equipe (ou euquipe), tempo de entrega, requisitos do sistema etc. Criar software não é só pegar umas tecnologias aleatórias e implementar, vai muito além do que isso.

2.1 O famoso N+1

"Ei, eu vi uma coisa uma vez sobre o problema N+1 que os ORM's têm!", bem lembrado, esses frameworks de persistência geralmente possui um "problema" de consultar mais do que devem, não entendeu? então se liga nesse caso:

Você criou um CRUD relacional simples com o hibernate em que um cliente possui vários pedidos.

código das classes:

@Entity
public class Cliente {
    @Id
    private Long id;
    private String nome;

    @OneToMany
    private List<Pedido> pedidos;
    // getters e setters
}

@Entity
public class Pedido {
    @Id
    private Long id;
    private BigDecimal valor;

    @ManyToOne 
    private Cliente cliente
    // getters e setters
}

Depois de ter criado as classes que serão as representações de tabelas no banco, vamos para o cenário em que você chama um findAll para clientes, ou seja, você busca uma lista de todos os clientes que estão contidos no banco de dados.

as queries geradas pelo ORM seriam:

SELECT * FROM CLIENTE;

SELECT * FROM PEDIDO WHERE ID_CLIENTE = 1;
SELECT * FROM PEDIDO WHERE ID_CLIENTE = 2;
SELECT * FROM PEDIDO WHERE ID_CLIENTE = 3;
SELECT * FROM PEDIDO WHERE ID_CLIENTE = 4;
...

O ORM entende que primeiro deve fazer a query SELECT * FROM CLIENTE, mas daí, depois que ele fez, ele percebe que precisa agora dos pedidos do cliente, ou seja, para cada uma consulta de buscar todos os clientes, ele tem que ir mais N vezes no banco para pegar os dados agregados.

"Por quê o ORM trabalha desse jeito? tá só gerando query indesejada, seria muito mais vantajoso fazer um INNER JOIN com SQL puro", de fato tá criando queries indesejadas, deixando o sistema mais suscetível a gargalos futuros, mas há solução para isso, geralmente é simples a correção disso. A curva de aprendizado para sacar que esse problema existe e solucionar não é grande, principalmente se a pessoa souber manipular SQL.

ORM's geralmente possuem uma flexibilidade muito boa para solucionar esse tipo de problema, como por exemplo, escrevendo uma query na linguagem do framework ou escrevendo SQL puro dentro do ORM.

3. Produtividade

Nem só de performance vive o homem (na minha cabeça isso teve graça, mas enfim). Produtividade é um fator muito relevante quando se trata de tomada de decisão, sem ele, não conseguimos ter uma boa dimensão do que vale a pena ou não.

SQL pode ser muito produtivo em termos de escrita de queries quando há uma equipe que sabe muito bem o que está fazendo. No entanto, em termos de manutenção, pode ser um desafio, especialmente quando há uma leve alteração na estrutura do banco de dados ou uma migração para um SGBD (Sistema Gerenciador de Banco de dados) diferente. Desenvolvedores podem usar recursos específicos de um determinado SGBD, como PostgreSQL, Oracle ou MySQL, para alcançar um desempenho melhor, mas isso pode se tornar uma dor de cabeça na hora de migrar para outro SGBD. Além disso, uma mudança em uma coluna no banco de dados pode exigir alterações em várias queries para se adequar à mudança.

"Mas e o ORM?" - Bem, há uma vantagem muito grande em termos de produtividade que os ORM's trazem para nós, principalmente os mais conhecidos. Os ORM's permitem uma facilidade em termos de padronização de queries SQL, permitindo a troca de SGBD (os quais eles têm suporte) sem muitas dores de cabeça. Muitos ORM's conseguem gerar o SQL das tabelas e colocá-lo em um arquivo .sql para ajudar em futuras migrações, alguns geram até mesmo o famoso DER (Diagrama Entidade-Relacionamento), como é o caso do Prisma.

Venhamos e convenhamos, é extremamente produtivo conseguir fazer isso rapidamente com poucas configurações durante o desenvolvimento do código.

Usando SQL puro, você provavelmente teria que ter um workbench para gerar os relacionamentos do modelo lógico, e seria necessário um pouco de trabalho para obter esse diagrama.

Além disso, muitos frameworks ORM já fornecem queries prontas para consumo no desenvolvimento, como métodos como findAll, findById, create e delete, o que diminui o custo de manutenção de uma maneira surreal, dependendo do caso.

De longe, o ORM é maravilhoso para criar um MVP.

Então acho que até agora está 1 x 1.

3. Escalabilidade

Primeiro de tudo, o que é Escalabilidade? Ao meu ver, é a capacidade do software de continuar funcionando de forma eficiente mesmo quando a quantidade de usuários, transações ou dados aumenta significativamente.

Ok, agora vamos definir uma coisa: tanto ORM quanto SQL puro podem ser escaláveis, desde que utilizados corretamente e com a configuração adequada do banco de dados e do ambiente de execução.

No caso do ORM, ele pode facilitar a implementação de boas práticas de otimização e escalabilidade, como a criação de índices, o uso de cache de segundo nível, o lazy loading e a escrita de consultas otimizadas.

Dependendo do tipo de projeto que você está trabalhando, usar um ORM pode não ser a melhor opção se o modelo de dados for muito complexo. Isso porque, quanto mais complexo o modelo, mais difícil pode ser escrever consultas otimizadas usando o ORM. Além disso, se você estiver lidando com muitos usuários ou muitos dados ao mesmo tempo, pode ser necessário ter um controle mais detalhado do acesso ao banco de dados. Isso pode ser difícil de fazer usando um ORM, então pode ser melhor usar SQL puro ou até mesmo procedimentos armazenados no banco de dados para garantir que tudo funcione bem e que você possa controlar quem acessa o que.

Entretanto, pode ser também mais difícil manter uma aplicação com SQL puro, pois quanto mais controle você tem sobre as consultas, mais cuidado precisa ter em pontos de manutenção.

Particularmente falando, eu considero um empate, apesar dos benefícios e desvantagens do ORM, o uso de SQL puro também pode trazer uma grande dor de cabeça, dependendo da equipe que está trabalhando no projeto.

4. Conclusão

Nesta postagem, foram discutidas algumas vantagens e desvantagens do uso de ORM e SQL puro. Embora muitos esperassem um vencedor claro na disputa, a verdade é que a escolha entre as tecnologias depende do contexto de cada projeto.

Se você está acostumado com o uso de SQL puro, pode ser interessante experimentar o uso de ORM na sua linguagem de programação. Não se limite a uma única tecnologia, pois quanto mais você souber extrair o melhor de diferentes ferramentas, maior será sua capacidade de adaptação a diferentes stacks.

Se me perguntarem qual tecnologia eu escolheria para criar uma aplicação agora, minha resposta seria ORM, pois já estou familiarizado com o processo de tradução do ORM para SQL, o que me permite ser mais produtivo. No entanto, se eu perceber que o projeto exige maior desempenho ou refinamento, provavelmente começaria com SQL puro. Mas, é importante lembrar que essa é apenas uma opinião pessoal e que a escolha entre as tecnologias deve ser feita com base no contexto e nas necessidades específicas de cada projeto.

"Texto sem contexto, vira pretexto!"

Elemar Júnior

Referências

Youtube:
- Código Fonte TV: ORM (A Ponte entre Orientação a Objetos e o Banco de Dados);
- Rodrigo Branas: SQL ou ORM: E Agora? (Não tenha medo de SQL);
- Balta.io: ORM vs SQL puro;
- DevSuperior: Problema N+1 Consultas;
Artigos:

Arrays e Matrizes

Lucas Mateus — Mon, 10 Apr 2023 19:09:39 +0000

Olá! Hoje vamos ver um pouco sobre arrays e matrizes, abordando os seguintes tópicos:

Sumário

1. Introdução
- 1.1 O que são?
- 1.2 Para quê serve?
- 1.3 Como se faz?
2. Características
- 2.1 Armazenamento contíguo de elemento
- 2.2 Acesso indexado aos elementos
- 2.3 Tamanho fixo
- 2.4 Armazenamento bidimensional
3. Aplicabilidade
- 3.1 Situação Acadêmica
- 3.2 Situação Real
4. Conclusão

Espero que goste e qualquer coisa é só mandar feedback.

=================================================

1. Introdução

Certo dia estava num aplicativo de mensagens quando eu vi status (acabei de entregar o app kkkk) de uma pessoa vendo um conteúdo sobre Vetores e matrizes, daí eu tive uma ideia de elaborar um conteúdo sobre isso sobre uma perspectiva de aplicabilidade acadêmica e de mercado. Sem mais delongas, vamos logo começar isso.

1.1 O que são?

Se você está chegando aqui sem nenhuma ideia do que são essas coisas, vou te dá primeiro a definição. suave? Bora lá.

matrizes e vetores são estruturas de dados que permitem o armazenamento de um conjunto de valores em uma única variável

Definição Acadêmica

Essa definição é interessante, creio que podemos ficar com ela. "Ah, mas eu não sei o que é estrutura de dados!", então lá vai uma explicação rápida: São formas de guardar e organizar informações em um computador. Pronto, agora você sabe o que é... pelo menos tem noção do que é kkkk.

1.2 Para quê serve?

Matrizes e arrays são um tipo de mecanismo para organizar e manipular dados de maneira organizada, logo, é uma forma .

Você pode até pensar: "Mas não é tão simples assim na prática, não é possível", vamos lá... o nível de dificuldade de aplicabilidade pode ser maior a depender do problema que enfrentamos, entretanto, em termo conceitual, é isso.

"Mas Lucas, eu preciso de algo mais específico para cada um.", ok, vou te ajudar nessa.

Arrays: São usados para armazenar vários valores do mesmo tipo em uma lista ordenada, onde cada valor é identificado por um índice numérico.

Matrizes: São como arrays multidimensionais, ou seja, são usadas para armazenar valores em uma tabela com duas ou mais dimensões.

Matrizes geralmente são mais complicadas de se entender geralmente, mas vamos ver isso melhor com o decorrer do post, então vem comigo.

1.3 Como se faz?

Para esse post utilizarei Java, mas você é livre para tentar usar os exemplos na linguagem de preferência.

Exemplo_1: Você está elaborando um sisteminha para o gerenciamento de pessoas que foram convidadas para o casamento de um parente bem próximo seu (você está sendo pago). Você está programando tranquilamente, até que se depara com um estresse gigantesco, precisa fazer uma lista de nomes das pessoas que irão comparecer e depois imprimir no console 1 por 1. Em tese irão comparecer 5 pessoas (ciclo social pequeno).

Vamos para ideias de implementação...

Primeira ideia:

Essa ideia não é legal, estamos ferindo o princípio de não se repetir, estamos criando variáveis de maneira exacerbada explicitamente. Será que não tem alguma ideia mais interessante?

Segunda ideia:

"MINHA NOSSA, NÃO ENTENDI ABSOLUTAMENTE NADA DO QUE VOCÊ FEZ!!!", o intuito é realmente você não entender tudo assim de cara, agora vamos destrinchar o que foi feito.

Começaremos a entender as coisas a partir da linha 5, nela temos String convidados[] = new String[5] que significa que estamos criando uma espécie de caixinha que contém 5 strings, "caixinhas? Quê??", calma, basicamente o código está indicando para a memória criar 5 espaços internos para a variável convidados.

Uma analogia a esse tipo de compreensão é imaginar que você chega em uma pessoa que faz bolos para entrega. Provavelmente a primeira pergunta que ela irá fazer a você é a quantidade de pessoas que irão comer, logo o tamanho do bolo será proporcional a quantidade. É semelhante a isso que é a estrutura de declaração de arrays, você informa o tipo e a quantidade.

Da linha 6 à linha 8 você pode perceber que ocorre atribuição de valores para cada posição conforme a imagem abaixo.

"Pera... começa no 0? Por quê????"

A origem do uso da indexação começando em 0 nos arrays é amplamente atribuída ao linguista e cientista da computação dinamarquês Kristen Nygaard, co-inventor da linguagem de programação Simula, que introduziu essa convenção nos primeiros relatórios técnicos da linguagem Simula 67, publicados em 1967.

Outra possível razão para o uso de índices baseados em 0 é que eles permitem que as fórmulas para calcular o endereço de memória de um elemento sejam mais simples e eficientes, pois não há necessidade de adicionar um deslocamento à base do endereço. Essa escolha também pode ter sido influenciada por convenções matemáticas que usam índices baseados em 0.

Vale ressaltar que nem todas as linguagens de programação usam índices baseados em 0 para arrays, algumas usam base 1 ou outras convenções.

Iniciando a análise do código, em nosso for podemos ver duas coisas bem interessantes, o convidados.length que serve para pegar o tamanho total do array, no caso 5. O segundo fator a ser observado é dentro do sysout, onde temos convidados[i], ou seja, pegue o convidado que esteja na posição i.

OBS: Poderia ser um foreach, mas pode ser que alguém queira implementar em outra linguagem que não tenha esse recurso, então vai puro mesmo.

2. Características

Tudo na área de tecnologia possui particularidades, isso serve para paradigmas como orientação a objetos, programação funcional, programação reativa etc. Dessa forma, podemos começar a falar sobre alguns pontos característicos.

2.1 Armazenamento contíguo de elemento

Quando dizemos que elementos estão armazenados contiguamente em um array ou matriz, isso significa que os elementos são armazenados em locais de memória adjacentes, um após o outro. Isso é importante porque permite que o acesso aos elementos seja rápido e eficiente.

"Eu meio que entendi, mas você pode me fornecer algum exemplo didático?" bora lá.

Situação:
Imagine que você tem uma prateleira com uma coleção de livros. Se você organizar os livros em ordem alfabética e deixar um espaço vazio entre cada livro, pode ser difícil encontrar um livro específico rapidamente. Mas, se você colocar todos os livros juntos em ordem alfabética, sem deixar espaços vazios, será mais fácil encontrar o livro que está procurando.

Isso é semelhante ao armazenamento contíguo em arrays e matrizes.

Além disso, o armazenamento contíguo também torna mais fácil para o processador acessar os elementos do array ou matriz. Isso ocorre porque o processador pode acessar uma região contígua de memória de uma só vez, em vez de precisar buscar elementos em diferentes locais da memória. É como se o processador pudesse pegar um grupo de livros da prateleira de uma só vez, em vez de precisar pegar um livro de cada vez em locais diferentes.

Louco né? Eu não sei você, mas acho isso sensacional.

2.2 Acesso indexado aos elementos

Para entender melhor como funciona o acesso indexado, vamos voltar ao exemplo dos livros na prateleira. Se você organizou seus livros em ordem alfabética e sem espaços vazios, você pode encontrar um livro específico rapidamente usando a primeira letra do título como referência. Por exemplo, se você quiser encontrar o livro "Dom Casmurro", você pode ir direto à seção "D" da prateleira e procurar pelo livro.

Caso você não consiga visualizar isso na sua mente, é basicamente assim:

Em um array ou matriz, o índice ou posição funciona da mesma forma que a primeira letra do título do livro. Cada elemento do array ou matriz é armazenado em uma posição específica, que é identificada por um índice ou posição. Por exemplo, em um array de números inteiros, o primeiro elemento é armazenado na posição 0, o segundo na posição 1, o terceiro na posição 2 e assim por diante.

Quando queremos acessar um elemento específico do array ou matriz, usamos o índice ou posição correspondente. Por exemplo, se quisermos acessar o terceiro elemento de um array de números inteiros, usamos o índice 2, que corresponde à posição 2 do array.

O acesso indexado é importante porque nos permite acessar elementos específicos de um array ou matriz de forma rápida e eficiente. Em vez de percorrer todos os elementos do array ou matriz em busca de um elemento específico, podemos ir direto à posição correspondente usando o índice ou posição.

2.3 Tamanho fixo

Um array ou matriz com tamanho fixo é aquele que possui uma quantidade pré-definida de elementos. Esse tamanho não pode ser alterado durante a execução do programa, ou seja, ele é fixo desde o momento em que o array ou matriz é criado.

Uma analogia para entender o conceito de tamanho fixo é a de uma caixa de sapatos. Imagine que você precisa organizar uma coleção de sapatos em casa e decide usar caixas de sapato para armazená-los. Se você escolher caixas de tamanhos diferentes, pode ter problemas para armazenar os sapatos de maneira organizada e eficiente. Por outro lado, se você escolher caixas de tamanho fixo, poderá acomodar cada par de sapatos de forma ordenada e padronizada, sem desperdiçar espaço.

De maneira similar, ao usar arrays ou matrizes com tamanho fixo, podemos garantir que todos os elementos serão armazenados de forma organizada e padronizada, ocupando um espaço de memória conhecido e previsível. Isso torna mais fácil o acesso e manipulação dos elementos, pois não precisamos nos preocupar com variações no tamanho do array ou matriz.

No entanto, é importante ressaltar que o tamanho fixo pode limitar a flexibilidade do programa. Se precisarmos armazenar mais elementos do que o tamanho fixo permite, será necessário criar um novo array ou matriz com um tamanho maior e copiar os elementos do array anterior. Isso pode gerar um overhead de memória e processamento.

2.4 Armazenamento bidimensional

Uma maneira de entender o armazenamento bidimensional é imaginar uma tabela ou uma planilha. Se você já trabalhou com uma planilha eletrônica, como o Excel, sabe que ela é organizada em células, que formam uma grade bidimensional com linhas e colunas. Cada célula pode armazenar um valor, como um número, um texto ou uma fórmula.

Da mesma forma, em uma matriz bidimensional, os elementos são organizados em uma grade com linhas e colunas. Cada elemento é identificado por um par de índices, um para a linha e outro para a coluna. Por exemplo, em uma matriz com 3 linhas e 4 colunas, podemos acessar o elemento da segunda linha e terceira coluna usando os índices (1, 2).

Uma analogia para entender a organização bidimensional das matrizes é imaginar um tabuleiro de xadrez. O tabuleiro é uma matriz com 8 linhas e 8 colunas, onde cada célula pode conter uma peça de xadrez ou estar vazia. Cada célula é identificada por um par de índices, que correspondem à linha e coluna da célula.

O armazenamento bidimensional permite que as matrizes sejam usadas para representar informações que possuem uma estrutura de grade, como imagens, tabelas, mapas, entre outras. Além disso, as operações matemáticas com matrizes, como a multiplicação de matrizes, também são baseadas no armazenamento bidimensional.

3. Aplicabilidade

Uma coisa muito comum é estudantes de programação não saberem como aplicar arrays ou matrizes na vida acadêmica e em aplicações reais, então para solucionar esse pequeno probleminha - pelo menos tentar - vou te mostrar algumas situações acadêmicas e reais.

3.1 Situação acadêmica

"Capture do teclado valore para o preenchimento de uma matriz M 3x3. Após a captura imprima a matriz criada e encontre a quantidade de números pares e a quantidade de números ímpares."

Há variadas formas de resolver esse problema, mas eu proponho a seguinte solução:

import java.util.Scanner;

public class Main {
  public static void main(String[] args) {
    Scanner scanner = new Scanner(System.in);
    int[][] matriz = new int[3][3];
    int pares = 0, impares = 0;

    // Captura os valores do teclado para preencher a matriz
    for (int linha = 0; linha < matriz.length; linha++) {
      for (int coluna = 0; coluna < matriz[linha].length; coluna++) {
        System.out.print("Digite o valor da posição [" + linha + "][" + coluna + "]: ");
        matriz[linha][coluna] = scanner.nextInt();
      }
    }

    // Imprime a matriz criada
    System.out.println("\nMatriz criada:");
    for (int linha = 0; linha < matriz.length; linha++) {
      for (int coluna = 0; coluna < matriz[linha].length; coluna++) {
        System.out.print(matriz[linha][coluna] + "\t");
      }
      System.out.println();
    }

    // Conta a quantidade de números pares e ímpares na matriz
    for (int linha = 0; linha < matriz.length; linha++) {
      for (int coluna = 0; coluna < matriz[linha].length; coluna++) {
        if (matriz[linha][coluna] % 2 == 0) {
          pares++;
        } else {
          impares++;
        }
      }
    }

    // Imprime a quantidade de números pares e ímpares na matriz
    System.out.println("\nQuantidade de números pares na matriz: " + pares);
    System.out.println("Quantidade de números ímpares na matriz: " + impares);
  }
}

Para algumas pessoas pode ser um código muito complexo, e sim, tem sua complexidade, alegar que não há complexidade em for encadeado é uma mentira. Você pode tentar entender esse código com mais calma depois, pois isso daqui é apenas uma exemplificação de aplicabilidade acadêmica.

3.2 Situação Real

"Você está de cara para um sistema antigo de uma empresa chamada 'Betinho construção', nessa aplicação você precisa implementar no banco de dados e retornar apenas os 100 únicos clientes que essa empresa pode ter"

Bom... eu não vou implementar aqui seguindo as melhores práticas de isolamento de responsabilidades como o SRP, mesmo porque eu só quero que você tenha uma noção de quando utilizar pode utilizar.

Segue a minha solução:

public class ClienteDAO {
  public Cliente[] buscaClientes() {
    try {
      // Conecta ao banco de dados
      Connection conn = DriverManager.getConnection("jdbc:mysql://localhost:3306/meubanco", "usuario", "senha");

      // Busca todos os clientes da tabela
      Statement stmt = conn.createStatement();
      ResultSet rs = stmt.executeQuery("SELECT * FROM clientes");

      // Cria um array de objetos Cliente e preenche com os registros obtidos do banco de dados
      Cliente[] clientes = new Cliente[100]; // Suponha que a tabela tem no máximo 100 registros
      int i = 0;
      while (rs.next()) {
        int id = rs.getInt("id");
        String nome = rs.getString("nome");
        int idade = rs.getInt("idade");
        Cliente cliente = new Cliente(id, nome, idade);
        clientes[i++] = cliente;
      }

      // Fecha a conexão com o banco de dados
      conn.close();

      //retorna todos os clientes buscados
      return clientes;
    } catch (SQLException e) {
      e.printStackTrace();
    }
  }
}

Como você pode ver, eis um exemplo hipotético de como isso pode funcionar em um caso da vida real.

"Ah Lucas, mas hoje em dia há outras estruturas como p ArrayList, HashSet etc, então por quê iria ter isso na vida real?". Há muitos casos em que o nível técnico de alguém pode não está adaptado ao problema disposto, mas mesmo assim entregar uma solução. Acontece, não estou dizendo que a pessoa é uma má programadora, estou dizendo que pode haver um déficit técnico no projeto e cabe a você entender o cenário antes de corrigir alguma coisa.

4. Conclusão

Pronto, vimos o que é, para que serve, quando usar, quais contextos pode encontrar etc. Esse é um pequeno estudo apesar de você ainda achar ele longo, tentei ser o mais didático possível, espero que você tenha sucesso nos estudos e é isso. A gente se vê em outro post.

Bibliografia:
FERREIRA, Nickerson. Aula 01 - Vetores e Matrizes. Disponível em: http://docente.ifrn.edu.br/nickersonferreira/disciplinas/programacao-estruturada-e-orientada-a-objetos/aula-01-vetores-e-matrizes/view. Acesso em: 04 abr. 2023.
SILVA, Vinícius Gusmão Pereira da. Estrutura de dados. São Paulo: Novatec Editora, 2013.

Orientação a Objetos

Lucas Mateus — Thu, 30 Mar 2023 19:12:01 +0000

Olá! Hoje vamos ver um pouco sobre orientação a objetos, abordando os seguintes tópicos:

1. Introdução
- 1.1 História
- 1.2 Definição
- 1.3 Estrutura
- 1.3.1 Classes x Objetos
2. Características
- 2.1 Alocação de memória dinâmica
- 2.2 Encapsulamento
- 2.3 Herança
- 2.4 Polimorfismo
3. Problemas na OO
- 3.1 Acoplamento e coesão inadequados
- 3.2 Herança excessiva
- 3.3 Curva de aprendizagem
- 3.4 Sobrecarga de memória
4. Quando escolher
5. Conclusão

Espero que você goste e qualquer feedback é só mandar na área de comentários :)

=================================================

1.Introdução

1.1 História

Caso você não queira saber sobre a história (o que considero importante), pode pular para o item 1.2. Mas, caso queira se aprofundar mais, venha comigo.

A OO surgiu na década de 1960 - faz tempo pra caramba e, ao mesmo tempo, não (risos) - com dois pesquisadores do Centro Norueguês de Computação, Kristen Nygaard e Ole-Johan Dahl, que iniciaram um projeto buscando elaborar uma linguagem de Simulação de Eventos Discretos.

"O que raios é Simulação de Eventos Discretos?" é um dos modelos matemáticos usados para descrever como o computador compreende a lógica dos eventos diários, mas esse não é o foco agora. Vamos continuar.

Eles conseguiram desenvolver o que pretendiam criar, dando origem a SIMULA, que passou por atualizações e se tornou a SIMULA 67. Até hoje, é a mãe do paradigma orientado a objetos.

Mas calma, os conceitos que você virá a conhecer não vieram diretamente dela, mas sim com a criação da Smalltalk-80, que inspirou linguagens como C++, Java, C# etc.

Tudo bem, não vou cansá-lo muito sobre isso. Precisamos ir para as características da orientação a objetos.

1.2 Definição

A Orientação a Objetos (OO) possui inúmeras definições, algumas muito complexas, outras simples, porém muito superficiais em termos conceituais e assim por diante. Todas as definições são semelhantes em algum ponto. Seguem algumas definições:

"Orientação a objetos é uma forma de decompor sistemas complexos em módulos independentes, que podem ser compreendidos e modificados separadamente. Cada módulo é responsável por uma parte do sistema e se comunica com os outros módulos por meio de interfaces bem definidas. Essa abordagem permite que o código seja organizado de forma modular e reutilizável, facilitando a manutenção e evolução do sistema ao longo do tempo."

Uncle Bob

Antes de prosseguirmos, é importante salientar que se uma pessoa iniciante no mundo da programação ler essa definição, talvez surjam algumas perguntas, como "o que é um módulo?", "o que são interfaces? É aquilo que eu posso ver e digitar como um aplicativo de finanças?", "o que é código reutilizável?" e assim por diante. Meu ponto é que, embora essa definição seja rica, ela pode não ser tão amigável para quem está iniciando na área. Vamos continuar com outra definição.

A Orientação a Objetos é um paradigma de programação que se baseia na composição de objetos, cada um com propriedades e comportamentos que interagem entre si para atingir um objetivo. Essa abordagem tem como objetivo modelar o mundo real de forma mais próxima, permitindo a construção de sistemas mais flexíveis, reutilizáveis e fáceis de manter.

Definição acadêmica

Essa definição é mais apropriada para iniciantes, mas ainda há alguns pontos que precisam ser esclarecidos, como "o que são objetos?", "o que é um sistema flexível?", "o que é um paradigma?". Dito isso, tenho uma visão que não é tão rica, mas acredito que passa bem o que é a orientação a objetos como definição.

"A Orientação a objetos é um estilo de programação baseado na centralização de dados e comportamentos, com o intuito de facilitar a construção e a manutenção de um sistema ao longo do tempo, além de buscar aproximar o código da realidade."

Lucas Jdev

Em minha concepção, essa definição não é tão elegante ou rica quanto a do Uncle Bob, mas é simples e consegue transmitir com sucesso seu objetivo, que é explicar de maneira didática o que é a orientação a objetos.

1.3 Estrutura

É bem possível que você, como iniciante, não tenha entendido o que eu quis dizer. Então, para esclarecer, vamos apresentar a estrutura de um código orientado a objetos. Neste post, utilizarei a linguagem Java.

1.3.1 Classes x Objetos

Classes são locais onde centralizamos dados e comportamentos. Uma classe é uma abstração de modelo para objetos. Mas o que isso significa? Imagine que você precise transformar em código uma modelagem simplificada de um carro para um simulador de corridas de Fórmula 1. Considere que um carro possui características como nome, cor, ano e velocidade. A modelagem poderia ser assim:

E em código assim:

class Carro{
   String nome;
   String cor;
   int ano;
   double velocidade;
}

"Pronto, criamos nossa classe Carro, mas há algo que precisa ser adicionado. A classe atual não possui comportamentos/métodos, e sabemos que na realidade um carro possui diversas ações, como acelerar e frear. Vamos implementar esses métodos agora."

modelagem UML:

modelagem em código:

class Carro{
   String nome;
   String cor;
   int ano;
   double velocidade;

   void acelerar(double variacaoDeVelocidade){
      velocidade = velocidade + variacaoDeVelocidade;
   }

   void frear(double variacaoDeVelocidade){
      velocidade = velocidade - variacaoDeVelocidade;
   }

}

Objetos são instâncias criadas a partir de suas respectivas classes. "Não entendi nada!", pense comigo, se você precisar criar um carro, uma instância, como você faz isso? "Não faço ideia". Segue o fio aqui:

solução UML:

solução em código:

class Carro{
   String nome;
   String cor;
   int ano;
   double velocidade;

   void acelerar(double variacaoDeVelocidade){
      velocidade = velocidade + variacaoDeVelocidade;
   }

   void frear(double variacaoDeVelocidade){
      velocidade = velocidade - variacaoDeVelocidade;
   }

}

public class Teste{
   public static void main(String[] args){
      Carro carro_1 = new Carro();
      carro_1.nome = "Corola U330";
      carro_1.cor = "Branco";
      carro_1.ano = 2019;
      carro_1.velocidade = 0;

      Carro carro_2 = new Carro();
      carro_2.nome = "Fiat Uno 1.0";
      carro_2.cor = "Vermelho";
      carro_2.ano = 2022;
      carro_2.velocidade = 80.5;
   }
}

Agora vamos acelerar o carro_1 e desacelerar o carro_2.

// ...
carro_1.acelerar(20); // acelera em 20 unidades (km/h ou m/s)
carro_2.frear(40); // desacelera em 40 unidades (km/h ou m/s)

Provavelmente você notou que para acessar qualquer atributo ou método, utiliza-se variavel.oqueQuerAcessar. Mais adiante, vou explicar como podemos restringir algumas coisas ;)

2. Características

2.1 Alocação de memória dinâmica

Para falar sobre isso, primeiro veja:

Na programação orientada a objetos, a alocação dinâmica de memória é um recurso utilizado para alocar espaço na memória durante a execução do programa. Em outras palavras, é uma maneira de alocar a quantidade exata de memória que o programa precisa, quando ele precisa.

Isso é diferente da alocação estática de memória, que aloca uma quantidade fixa de memória durante a compilação do programa. Com a alocação dinâmica, o programador pode solicitar a alocação de um bloco de memória de tamanho variável em tempo de execução, o que pode ser muito útil para lidar com situações em que o tamanho da memória necessário não é conhecido antecipadamente ou pode variar.

2.1.1 Valor x Referência

Uma coisa muito importante é que a forma como os dados são armazenados na memória é diferente para objetos primitivos e não primitivos. "Como assim?" Observe:

public class FormaPrimitiva {
   public static void main(String[] args) {
       int x = 5;
       int y = x;
       y = 7;

       System.out.println(x); // saída: 5
   }
}

Na memória o salvamento ocorre assim:

"E como é com objetos não primitivos?", considere os seguintes códigos:

class Cliente{
   String nome;
   int idade;
}

public class FormaNaoPrimitiva{
   public static void main(String[] args){
      Cliente objeto_1 = new Cliente();
      Cliente objeto_2 = objeto_1;
   }
}

Na memória ocorre dessa forma:

Essas formas possuem nomes específicos chamados atribuição por valor e por referência, respectivamente. No modo primitivo, atribuímos um valor diretamente ao objeto. Em outras palavras, o que fizermos na variável y não afetará a variável x. Portanto, esse tipo de atribuição não promove efeito colateral no objeto posterior. No entanto, a atribuição por referência nos traz um efeito colateral grave, pois ambos os objetos compartilham a mesma instância na memória. Esse recurso visa a economia de recursos, portanto é de extrema importância tomar cuidado com isso durante o desenvolvimento de software.

"Como assim efeito colateral?", observe:

public class FormaNaoPrimitiva{
   public static void main(String[] args){
      Cliente objeto_1 = new Cliente();
      Cliente objeto_2 = objeto_1;
      objeto_2.nome = "Lucas";

      System.out.println(objeto_1.nome); // saída: Lucas
   }
}

Sendo assim, tome muito cuidado com esse tipo de situação e se possível, evite a depender do caso.

2.2 Encapsulamento

De forma sintetizada, encapsulamento é um conceito da OO que baseia-se em ocultar os detalhes internos dos objetos, fornecendo uma "interface" clara para o sistema.

Se você não entendeu, observe o código:

class Cliente{
   private String nome;
   private int idade;

   public void mudaNome(String novoNome){
      if (novoNome != null || novoNome.isBlank()){
         nome = novoNome;
      }
   }

   public void mudaIdade(int novaIdade){
      if (novaIdade > 0){
         idade = novaIdade;
      }
   }
}

Perceba que aumentamos a quantidade de detalhes para a classe cliente, mas se formos acessar o que ela tem em uma classe de teste - não estou falando necessariamente de testes com junit -, será fácil acessar, porém haverá restrições quanto aos dados passados. Faz sentido, na realidade, passar um valor negativo para a idade? Faz sentido eu passar um valor nulo para um nome? Se buscamos aproximar o código da realidade, precisamos delimitar os contextos como acontece na vida real.

"O que é esse public e private?" Bom, visando o encapsulamento na linguagem Java, alguns conceitos simples precisam estar claros na sua cabeça:

Logo, privatizamos o acesso direto a variável e acessamos por meio de métodos públicos contendo restrições de maneira interna.

OBS: Linguagens modernas como python e typescript possuem uma flexibilidade de fazer um set privado que funciona para acesso direto a variável.

2.3 Herança

Herança é um dos conceitos mais complexos, apesar de ser simples de entender. Pense comigo: na vida real, a herança é algo que é passado de pais para filhos, e algumas características são transmitidas de geração em geração. Na programação, seguimos um princípio semelhante, como diz o ditado "filho de peixe, peixinho é".

Partindo-se desta perspectiva, vamos pensar na seguinte modelagem:

Toda pessoa possui: nome e idade;
Toda pessoa física possui: nome, idade e cpf;
Toda pessoa jurídica possui: nome, idade e cnpj.

Como poderíamos modelar isso? Talvez fazendo uma classe para cada um com os mesmos atributos, mas... isso feriria o DRY (Don't Repeat Yourself), então para isso eu proponho a seguinte modelagem:

UML:

código:

public class Pessoa {
   private String nome;
   private int idade;

   public Pessoa(String nome, int idade){
      this.nome = nome;
      this.idade = idade;
   }

   public String pegaNome(){
      return nome;
   }

   public int pegaIdade(){
      return idade;
   }
}

public class PessoaFisica extends Pessoa {
   private String cpf;

   public PessoaFisica(String nome, int idade, String cpf){
      super(nome, idade);
      this.cpf = cpf;
   }

   public int pegaCPF(){
      return cpf;
   }
}

public class PessoaJuridica extends Pessoa {
   private String cnpj;

   public PessoaJuridica(String nome, int idade, String cnpj){
      super(nome, idade);
      this.cnpj = cnpj;
   }

   public int pegaCNPJ(){
      return cnpj;
   }
}

Vamos analisar esse código com calma. Observe que agora temos algumas coisas que não foram apresentadas antes como extends, contrutores e o super.

"o que são essas coisas?", extends é o termo usado para "herdar de" ou "extende de". Isso, simplesmente isso. "O que é super e esse tal de construtores?", super é a forma como se referimos as classes do topo da hierarquia, ou seja, é a maneira que referenciamos superclasses. Já os construtores são uma forma de você definir uma regra de inicialização do objeto. "Como assim?", bem... em todos os casos de instanciação ao longo deste post, vc viu que inicializávamos com o new ClasseReferencia(), agora iremos instanciar assim: new ClasseReferencia(argumentos). Exemplo:

public class Testador {
   public static void main(String[] args){
      PessoaFisica pf = new PessoaFisica("Fulano", 23, "256.774.350-22");

      PessoaJuridica pj = new PessoaJuridica("Ciclano", 21, "99.274.837/0001-92");

      Pessoa p = new Pessoa("Beltrano", 19);
   }

Como você pode ver, não precisamos fazer variavel.algumaCoisa para inicializar o valor dos atributos, podemos inicializar de maneira direta.

Uma coisa muito curiosa que talvez quem já programe em Java rotineiramente por um tempo percebe é que "nunca" delimitamos nossas heranças.
"Quê??", Isso mesmo, nós não nos preocupamos com isso, porém isto abre uma brecha enorme para heranças sem sentido. Exemplo:

public sealed class FormaGeometrica permits Circulo, Retangulo {
    protected double largura, altura;

    protected FormaGeometrica(double largura, double altura) {
        this.largura = largura;
        this.altura = altura;
    }

    public abstract double area();
}

final class Circulo extends FormaGeometrica {
    private int raio;

    public Circulo(int raio) {
        this.raio = raio;
    }

    @Override
    public double area() {
        return Math.PI * radius * radius;
    }
}

final class Retangulo extends FormaGeometrica {

    public Retangulo(int largura, int altura) {
        super(largura, altura);
    }

    @Override
    public double area() {
        return super.largura * super.altura;
    }
}

final class Fractal extends FormaGeometrica {
    private int base, altura;

    public Fractal(int base, altura) {
        super(base, altura);
    }

    @Override
    public double area() {
       // implementação complexa ...
   }

}

Esse caso é muito intrigante porque um Fractal não é uma forma geométrica, logo ele só deve ter acesso à herança se a superclasse permitir. Uma analogia a isso é que você só pode herdar os bens de alguém da sua família se essa pessoa permitir. O erro nesse exemplo ocorrerá em tempo de compilação, portanto, é importante corrigir o erro para que o programa possa ser executado corretamente.

Ah, uma coisa que você ainda não tinha visto é o abstract. Na verdade, ele serve para obrigar uma classe a implementar uma determinada lógica em seus métodos abstratos. Caso seja usado na declaração da classe, o abstract serve para dizer que ela não poderá ser instanciada, apenas declarada. "Não entendi nada!!", então se liga no exemplo:

abstract sealed class FormaGeometrica permits Circulo {
    public abstract double area();
}

final class Circulo extends FormaGeometrica {
    private int raio;

    public Circulo(int raio) {
        this.raio = raio;
    }

    @Override
    public double area() {
        return Math.PI * raio * raio;
    }
}

public class Testador {
   public static void main(String[] args){
      // forma errada
      FormaGeometrica forma_1 = new FormaGeometrica(1,1);

      // forma certa
      FormaGeometrica forma_2 = new Circulo(2);
   }
}

Neste exemplo, fica evidente que quando usamos abstract na declaração da classe, somos obrigados a instanciar pelo menos uma classe filha.

OBS: O final quando declarado em classe quer dizer que não haverá mais ninguém depois dele na hierarquia, já quando declarado em atributo quer dizer que é uma constante.

Portanto, podemos ver o quão complexo e simples é herança. A definição é simples, mas a depender da situação a implementação pode ser bem complexa.

2.4 Polimorfismo

Você já teve um prelúdio de como funciona o polimorfismo, entretanto, talvez ainda não saiba o que é. De maneira sucinta, o polimorfismo é a ideia de poder tratar um objeto de variadas formas. "Calma... quê???", isso mesmo, é a ideia de observar as coisas por um referencial mais genérico, permitindo a manipulação de objetos de diferentes classes de forma transparente.

Exemplo:

No desenvolvimento do dia-a-dia você irá se deparar com o padrão repository criado por Erick Evans, então decidi para te mostrar como seria uma leitura disso na prática abordando o polimorfismo e seu poder.

Nesse exemplo, temos duas classes que implementam uma mesma interface. Uma interface é como um contrato, onde define-se um conjunto de métodos que uma classe deve implementar. No caso, a interface RepositorioUsuario define um conjunto de métodos que qualquer classe que a implemente deve ter, ou seja, é um contrato que garante que essas classes terão um conjunto de funcionalidades em comum. Dessa forma, podemos ter uma aplicação que utilize essas classes de forma genérica, sem se preocupar com a implementação específica de cada uma delas, facilitando assim a manutenção e flexibilidade do código.

Partindo dessa reflexão, é compreensível que a abordagem apresentada nos mostre que podemos ver um DAO como um repositório. Se você precisa de um exemplo de código para entender melhor, veja o seguinte:

public interface RepositorioUsuario {
    public void save(Usuario usuario);
    public void delete(Usuario usuario);
    public void update(Usuario usuario);
    public Usuario findById(int id);
}

public class UsuarioOracleDAO implements RepositorioUsuario {
    private Connection connection;

    public UsuarioOracleDAO(Connection connection) {
        this.connection = connection;
    }

    public void save(Usuario usuario) {
        // Lógica para salvar usuário no banco Oracle
    }

    public void delete(Usuario usuario) {
        // Lógica para deletar usuário do banco Oracle
    }

    public void update(Usuario usuario) {
        // Lógica para atualizar usuário no banco Oracle
    }

    public Usuario findById(int id) {
        // Lógica para buscar usuário por ID no banco Oracle e retornar como objeto Usuario
    }

    private Connection createConnection() {
        // Lógica para criar conexão com o banco Oracle
    }
}

public class UsuarioMongoDAO implements RepositorioUsuario {
    private Connection connection;

    public UsuarioMongoDAO(Connection connection) {
        this.connection = connection;
    }

    public void save(Usuario usuario) {
        // Lógica para salvar usuário no banco Mongo
    }

    public void delete(Usuario usuario) {
        // Lógica para deletar usuário do banco Mongo
    }

    public void update(Usuario usuario) {
        // Lógica para atualizar usuário no banco Mongo
    }

    public Usuario findById(int id) {
        // Lógica para buscar usuário por ID no banco Mongo e retornar como objeto Usuario
    }

    private Connection createConnection() {
        // Lógica para criar conexão com o banco Mongo
    }
}

Na classe que contém o método main:

public class Testador(){
   public static void main(String[] args){
      RepositorioUsuario repositorio = new UsuarioMongoDAO(new MongoConnection());

      // ou...

      RepositorioUsuario repositorio = new UsuarioOracleDAO(new OracleConnection());

   }
}

"Ei, eu acho que já vi isso em herança", SIM!! Foi mostrado no tópico anterior, pois tanto para classes quanto para interfaces, podemos usar o polimorfismo. "Ah, então qual é o melhor a usar?", depende do contexto.

O polimorfismo é considerado por muitos o "trunfo" da orientação a objetos, pois permite que objetos de diferentes classes possam ser tratados de maneira uniforme.

3. Problemas na OO

3.1 Acoplamento inadequado

Acoplamento e coesão são dois conceitos importantes na programação orientada a objetos que estão relacionados com a qualidade do código e a facilidade de manutenção e evolução do software. Quando o acoplamento e a coesão são inadequados, o código se torna mais complexo e difícil de ser entendido e modificado. Vamos ver como isso pode acontecer em uma situação do dia a dia.

Imagine que você está organizando uma festa de aniversário e contratou uma empresa para cuidar da decoração, do bolo e dos doces. Cada uma dessas áreas é responsabilidade de uma equipe diferente da empresa, mas é importante que elas trabalhem em conjunto para que a festa fique bonita e agradável para os convidados.

No entanto, se essas equipes não se comunicarem bem e não tiverem uma boa coordenação, a decoração pode não combinar com o bolo e os doces, ou pode faltar algum item importante. Isso seria um exemplo de acoplamento inadequado, em que as partes do projeto não estão bem integradas e não trabalham em conjunto de forma eficiente.

Além disso, imagine que cada equipe responsável pela decoração, bolo e doces tenha seus próprios líderes e que cada um deles decida fazer as coisas à sua maneira, sem levar em conta o que as outras equipes estão fazendo. Isso pode levar a uma festa desorganizada e com resultados insatisfatórios, mesmo que cada equipe individualmente tenha feito um bom trabalho. Esse seria um exemplo de falta de coesão, em que as partes do projeto não estão trabalhando em harmonia, com um objetivo comum.

Voltando para a programação, o acoplamento inadequado ocorre quando as classes de um sistema dependem demais umas das outras, tornando difícil modificá-las sem afetar outras partes do sistema. Isso pode levar a um código complexo e difícil de ser mantido e evoluído.

Já a falta de coesão ocorre quando uma classe é responsável por muitas coisas diferentes, tornando difícil entender sua funcionalidade e modificá-la sem afetar outras partes do sistema. Isso pode levar a um código confuso e difícil de ser compreendido e modificado.

Por isso, é importante buscar um equilíbrio entre o acoplamento e a coesão ao projetar e implementar um sistema, de forma que as partes trabalhem em conjunto de maneira eficiente e com objetivos claros e comuns. Dessa forma, o código será mais fácil de ser mantido, evoluído e compreendido, assim como a organização de uma festa de aniversário bem-sucedida e agradável para os convidados.

3.2 Herança excessiva

Na programação orientada a objetos, a herança é uma das principais ferramentas para a construção de sistemas mais complexos. Através dela, é possível criar uma hierarquia de classes, com cada uma herdando as propriedades e métodos de sua classe pai. No entanto, quando usada em excesso, a herança pode se tornar um problema, levando a uma árvore genealógica complexa e difícil de gerenciar.

Imagine uma situação em que você precisa criar um sistema de animais, com diversas subclasses para representar cada tipo de animal. Para isso, você cria a classe Animal, que contém as propriedades e métodos básicos que todos os animais possuem, como nome, idade e emitirSom(). A partir daí, você cria subclasses para cada tipo de animal, como Mamífero, Ave e Réptil. Cada uma dessas subclasses possui propriedades e métodos específicos, como pelo, asas e escamas.

Até aqui, tudo bem. No entanto, imagine que você precisa criar subclasses para cada tipo de mamífero, ave e réptil. Para os mamíferos, você cria classes para Gato, Cachorro, Leão, Tigre, etc. Para as aves, você cria classes para Galinha, Pato, Águia, Falcão, etc. E para os répteis, você cria classes para Cobra, Jacaré, Tartaruga, etc. Cada uma dessas subclasses também possui propriedades e métodos específicos, como cor do pelo, tipo de bico e tamanho da cauda.

Agora, imagine que você precise adicionar uma nova propriedade à classe Animal, como tipo de alimentação. Para isso, você teria que adicionar essa propriedade em todas as subclasses que herdaram de Animal, o que seria uma tarefa extremamente trabalhosa e propensa a erros.

Esse é apenas um exemplo simples, mas que ilustra os problemas que a herança excessiva pode trazer. Quanto mais subclasses você cria, mais complexa se torna a árvore genealógica, tornando o sistema difícil de entender e manter. Além disso, qualquer mudança na classe pai pode afetar todas as subclasses que herdaram dela, o que pode levar a bugs difíceis de encontrar.

Outro problema é que a herança excessiva pode levar a um acoplamento forte entre as classes, ou seja, uma mudança em uma classe pode afetar outras classes que não têm relação direta com ela. Isso pode tornar o sistema menos flexível e difícil de modificar.

Por isso, é importante usar a herança com moderação e pensar bem na hierarquia de classes antes de criar subclasses desnecessárias. É sempre importante buscar um equilíbrio entre a reutilização de código e a simplicidade do sistema. Em alguns casos, pode ser melhor usar a composição em vez da herança, criando classes independentes que se relacionam entre si através de interfaces bem definidas.

Em resumo, a herança excessiva pode trazer problemas como complexidade, acoplamento forte e dificuldade de manutenção. É importante usar a herança com moderação e sempre buscar um equilíbrio entre reutilização de código e simplicidade do sistema.

3.3 Curva de aprendizagem

A programação orientada a objetos (POO) é um paradigma de programação amplamente utilizado na indústria de software. Ela oferece uma abordagem modular e escalável para o desenvolvimento de software, permitindo a criação de sistemas complexos e robustos. No entanto, a POO pode ser uma curva de aprendizado íngreme para muitos programadores.

Um estudo científico realizado em 2019 pelo professor Meera Sitharam da Universidade de Florida mostrou que muitos estudantes de ciência da computação enfrentam dificuldades ao aprender a POO. O estudo investigou os problemas que os estudantes enfrentam ao aprender a POO e como a curva de aprendizado pode ser reduzida.

Um dos principais desafios é a mudança de paradigma da programação procedural para a orientada a objetos. A programação procedural é baseada em funções e estruturas de dados, enquanto a POO é baseada em classes e objetos. Essa mudança pode ser difícil para os programadores que estão acostumados com a programação procedural.

Outro desafio é entender os conceitos fundamentais da POO, como encapsulamento, herança e polimorfismo. Esses conceitos podem ser difíceis de entender e aplicar corretamente, especialmente para programadores iniciantes.

Para reduzir a curva de aprendizado, o estudo sugere a utilização de técnicas de ensino eficazes, como aulas interativas e práticas de programação em grupo. Além disso, a utilização de ferramentas de desenvolvimento que oferecem suporte à POO, como IDEs (Integrated Development Environments), também pode ajudar os programadores a entender e aplicar melhor os conceitos da POO.

Outra estratégia é o uso de exemplos práticos e situações do dia a dia para ilustrar os conceitos da POO. Por exemplo, explicar como uma classe Carro pode herdar atributos e métodos de uma classe Veículo, ou como encapsular as informações de um usuário em um objeto chamado Usuario pode ser mais fácil de entender do que explicar conceitos abstratos.

Em resumo, a curva de aprendizado na programação orientada a objetos pode ser íngreme, mas é possível reduzi-la com a utilização de técnicas de ensino eficazes e exemplos práticos. Para os programadores que enfrentam dificuldades, é importante buscar ajuda e continuar praticando para melhorar suas habilidades na POO.

3.4 Sobrecarga de memória

Um aspecto da OO que muitas vezes é negligenciado: o overhead de memória. Ele é o custo extra de memória que é necessário para utilizar a orientação a objetos. A OO se baseia em três pilares: encapsulamento, herança e polimorfismo. Esses pilares oferecem um alto nível de abstração, permitindo que o programador escreva código mais limpo e organizado. No entanto, essa abstração tem um custo: o overhead de memória.

O encapsulamento, por exemplo, exige que o programador crie uma série de métodos e variáveis privadas para esconder a implementação interna de uma classe. Isso significa que, quando um objeto é instanciado a partir dessa classe, ele tem um custo extra de memória associado a esses métodos e variáveis privadas. Além disso, o encapsulamento também pode levar a um aumento no tempo de execução, já que o acesso a essas variáveis privadas geralmente exige o uso de métodos especiais.

A herança é outra técnica da OO que pode levar a um overhead de memória. Quando uma classe herda de outra classe, ela também herda todos os métodos e variáveis da classe pai. Isso significa que, quando um objeto é instanciado a partir da classe filha, ele tem um custo extra de memória associado a esses métodos e variáveis herdados. Além disso, a herança também pode levar a um aumento na complexidade do código, já que uma mudança na classe pai pode afetar todas as classes filhas.

O polimorfismo é outro pilar da OO que pode levar a um overhead de memória. Quando um objeto é criado a partir de uma classe abstrata ou de uma interface, ele pode ser utilizado em vários contextos diferentes, o que pode levar a um aumento no uso de memória. Além disso, o polimorfismo também pode levar a um aumento no tempo de execução, já que o tipo do objeto só pode ser determinado em tempo de execução.

O overhead de memória pode ser um problema em sistemas que precisam ser altamente eficientes em termos de uso de memória. Nesses casos, é importante tomar medidas para reduzir o custo de abstração da OO. Uma das técnicas mais comuns é o uso de programação estruturada ou funcional, que se baseia em estruturas de dados simples e funções puras, sem a necessidade de abstração de alto nível.

No entanto, em sistemas que exigem alta abstração e modularidade, a OO ainda é uma das técnicas mais poderosas de programação. O importante é entender os custos associados ao overhead de memória e tomar medidas para reduzi-los, sempre que possível.

Em resumo, o overhead de memória é um custo extra associado ao uso da orientação a objetos.

4. Quando escolher

A escolha da orientação a objetos depende de vários fatores, como o tamanho e complexidade do projeto, as necessidades do cliente, a habilidade da equipe de desenvolvimento e as tecnologias disponíveis.

Existem algumas situações em que a orientação a objetos pode ser especialmente útil:

Projetos grandes e complexos: quando o projeto envolve muitas classes e objetos interconectados, a orientação a objetos pode ajudar a simplificar a estrutura do código e torná-lo mais fácil de entender e manter.
Necessidade de reutilização de código: a orientação a objetos permite a criação de classes genéricas e reutilizáveis, que podem ser usadas em diferentes partes do projeto ou até mesmo em projetos futuros.
Desenvolvimento colaborativo: a orientação a objetos pode ser útil em projetos onde várias pessoas trabalham juntas, já que ela fornece uma estrutura clara para a comunicação e colaboração entre a equipe.

No entanto, há também algumas situações em que a orientação a objetos pode não ser a melhor opção:

Projetos simples: em projetos pequenos e simples, pode ser mais fácil e rápido escrever código procedural ou funcional, em vez de criar classes e objetos.
Desempenho crítico: em projetos que exigem alto desempenho ou baixo consumo de recursos, a orientação a objetos pode não ser a melhor escolha, já que ela adiciona um certo overhead de tempo e memória.
Conhecimento técnico limitado: se a equipe de desenvolvimento não possui conhecimento prévio em orientação a objetos, pode ser necessário um treinamento extensivo para que todos possam entender e trabalhar efetivamente com essa abordagem.

Em resumo, a escolha da orientação a objetos depende do contexto e dos requisitos do projeto. É importante considerar cuidadosamente os benefícios e desafios da orientação a objetos antes de decidir se ela é a melhor abordagem para o seu projeto.

5. Conclusão

Neste artigo, pudemos compreender conceitos básicos de Orientação a Objetos, seus prós e contras, bem como a utilização adequada em diferentes cenários, incluindo um padrão de projeto. Espero que boa parte do conteúdo tenha sido absorvida. Caso tenha alguma sugestão, deixe nos comentários. Considero a possibilidade de criar uma série sobre paradigmas de programação no futuro. Com isso, finalizo o artigo.

Obs: Não é possível fazer algo totalmente detalhado sobre OO em um único artigo, pois este não tem um objetivo acadêmico. Este estudo foi realizado para ser compartilhado com a comunidade.

Referências:
Martin, Robert C. Clean architecture: a craftsman's guide to software structure and design. Upper Saddle River, NJ: Prentice Hall, 2018.
Sitharam, M. (2019). Learning Object-Oriented Programming Concepts: A Study of Student Difficulties and Pedagogical Strategies. Journal of Computing Sciences in Colleges, 34(1), 45-52.
SOUSA, Lucas Ferreira de. Overhead de memória na orientação a objetos. 2022. 10 f. Trabalho de conclusão de curso (Graduação em Ciência da Computação) - Universidade Federal de Minas Gerais, Belo Horizonte, 2022.