Programação Orientada a Objetos em Java: fundamentos atuais para quem trabalha com infraestrutura

> Uma atualização da aula introdutória de POO1, originalmente elaborada em 2017.

Introdução

Quem trabalha com redes, servidores, cloud ou suporte de aplicações não precisa necessariamente atuar como desenvolvedor em tempo integral. Ainda assim, compreender como um programa é estruturado ajuda a dimensionar recursos, interpretar logs, avaliar riscos de implantação, automatizar tarefas e conversar melhor com equipes de desenvolvimento.

É nesse ponto que a Programação Orientada a Objetos (POO) se torna útil. POO não é uma linguagem nem uma receita obrigatória para todo sistema: é uma forma de organizar responsabilidades e comportamentos em um software. Java continua sendo uma excelente linguagem para estudar esses conceitos porque combina tipagem estática, uma biblioteca ampla, ferramentas maduras e execução sobre a Máquina Virtual Java (JVM).

Este artigo revisita os fundamentos da introdução original e atualiza vários pontos que mudaram desde 2017: o ciclo de versões do Java, a diferença entre JDK e runtime, o fim dos applets, a evolução de Java EE para Jakarta EE e o uso de recursos modernos como records e virtual threads.

Antes da orientação a objetos: algoritmo e decomposição

Todo software começa com um problema que precisa ser descrito com precisão. Um algoritmo é uma sequência finita de passos para transformar entradas em resultados. Na prática, esses passos podem envolver:

• entrada de dados;
• validação e processamento;
• armazenamento ou recuperação;
• comunicação com outros sistemas;
• saída, observabilidade e tratamento de falhas.

Programação linear, estruturada e modular são maneiras históricas e ainda úteis de decompor um problema. Sequência, decisão (`if`/`else`) e repetição (`for`, `while`) continuam presentes em Java moderno. A orientação a objetos acrescenta uma preocupação importante: quem é responsável por cada comportamento e quais dados precisam ser protegidos?

Uma boa decomposição reduz o acoplamento. Em vez de concentrar toda a lógica em um método enorme, podemos dividir o sistema em componentes pequenos, com contratos claros e testes independentes.

O que é orientação a objetos?

Na POO, uma classe descreve dados e comportamentos; um objeto é uma instância concreta dessa classe. Uma classe `Servidor` pode definir endereço, capacidade e operações como `iniciar()` ou `verificarSaude()`. Cada objeto representa um servidor específico.

Os quatro conceitos mais associados à POO são:

1. **Encapsulamento**: protege o estado interno e expõe apenas operações válidas.
2. **Abstração**: representa o que é relevante para o problema e esconde detalhes desnecessários.
3. **Herança**: permite especializar uma classe, mas deve ser usada com cuidado; nem toda relação conceitual justifica uma hierarquia.
4. **Polimorfismo**: permite que diferentes implementações atendam ao mesmo contrato, normalmente por meio de interfaces.

Na prática moderna, composição e interfaces costumam ser preferíveis a hierarquias profundas de herança. Isso facilita testes, substituição de componentes e evolução do sistema.

Java em 2026: o que mudou desde a aula original?

A aula-base mencionava Java 8 como a versão atual e descrevia applets, JRE separado e Java EE. Esses pontos precisam ser atualizados:

• O Java adota uma cadência de novas versões a cada seis meses. Java 25 foi lançado em setembro de 2025 e é uma versão de suporte prolongado (LTS). As versões LTS anteriores incluem Java 17 e Java 21; a escolha deve considerar a política de suporte da organização e a compatibilidade do ecossistema.
• O JDK é o pacote usado para desenvolver: inclui o compilador `javac`, ferramentas de diagnóstico e a JVM. Em distribuições modernas, não é adequado ensinar o JRE como um download separado obrigatório; para executar uma aplicação, usa-se uma distribuição compatível do Java Runtime, frequentemente instalada como parte de um JDK em ambientes de desenvolvimento.
• Applets e o plugin Java para navegadores deixaram de ser uma abordagem válida. Aplicações web atuais usam HTML, CSS, JavaScript e APIs de backend, que podem ser implementadas com Java, entre outras tecnologias.
• O antigo Java EE passou a ser Jakarta EE após a transferência das especificações para a Eclipse Foundation. Jakarta EE 11 requer Java SE 17 ou superior e inclui recursos como Jakarta Data e suporte a records em partes da plataforma.
• A JVM continua abstraindo o sistema operacional, mas “Write once, run anywhere” não elimina diferenças de arquitetura, sistema de arquivos, permissões, containers, bibliotecas nativas e configuração. Portabilidade exige testes e empacotamento corretos.

Do código-fonte ao processo em execução

Um exemplo simples:

public record Servico(String nome, int porta) {

public boolean portaValida() {

return porta >= 1 && porta <= 65_535;

}

}

public class Main {

public static void main(String[] args) {

Servico api = new Servico("api-pedidos", 8080);

System.out.println(api.nome() + ": " + api.portaValida());

}

}

O arquivo `.java` é compilado para bytecode (`.class`) pelo compilador. A JVM carrega e executa esse bytecode, aplicando verificações e otimizações em tempo de execução. O JIT (Just-In-Time Compiler) pode transformar trechos frequentemente executados em código nativo para melhorar o desempenho.

O `record` usado no exemplo, disponível desde Java 16, é apropriado para dados imutáveis e reduz código repetitivo de construtores, acessores, `equals`, `hashCode` e `toString`. Ele não substitui todas as classes: entidades com ciclo de vida complexo e invariantes elaboradas podem exigir uma implementação tradicional.

Memória, coleta de lixo e operação

Java administra automaticamente a memória dos objetos por meio da coleta de lixo (garbage collection). Isso elimina a necessidade de liberar manualmente cada objeto, mas não elimina problemas de memória. Aplicações podem reter referências por muito tempo, criar objetos em excesso ou consumir recursos externos, como conexões, arquivos e sockets.

Para infraestrutura, é importante observar:

• heap e limites de memória do processo;
• pausas e comportamento do coletor de lixo;
• número de threads e conexões;
• uso de CPU, latência e throughput;
• logs, métricas, traces e códigos de saída;
• diferenças entre execução local, container e ambiente cloud.

A JVM oferece ferramentas para análise, mas o diagnóstico deve começar por métricas e evidências, não por alterações arbitrárias em flags de memória.

Concorrência moderna com virtual threads

Serviços de rede frequentemente aguardam banco de dados, APIs ou arquivos. Em Java 21, virtual threads tornaram mais simples criar grande quantidade de tarefas concorrentes para operações bloqueantes, reduzindo o custo associado às threads tradicionais do sistema operacional. Elas não tornam automaticamente um algoritmo mais rápido e não substituem filas, limites de concorrência, timeouts ou circuit breakers.

Um exemplo didático:

try (var executor = java.util.concurrent.Executors.newVirtualThreadPerTaskExecutor()) {

for (int i = 0; i < 100; i++) {

int id = i;

executor.submit(() -> System.out.println("Tarefa " + id));

}

}

O código continua exigindo responsabilidade operacional: uma aplicação pode sobrecarregar um banco se iniciar tarefas sem limite. O recurso resolve parte do custo de gerenciamento de threads, não o controle de capacidade do sistema.

POO aplicada à infraestrutura

Considere uma aplicação que monitora serviços. Uma solução pouco modular poderia misturar coleta de dados, regra de alerta, envio de mensagem e gravação em banco em uma única classe. Uma solução orientada a objetos pode separar contratos:

interface VerificadorDeDisponibilidade {

Resultado verificar(String destino);

}

record Resultado(String destino, boolean disponivel, long latenciaMs) {}

final class Monitor {

private final VerificadorDeDisponibilidade verificador;

Monitor(VerificadorDeDisponibilidade verificador) {

this.verificador = verificador;

}

Resultado executar(String destino) {

return verificador.verificar(destino);

}

}

`Monitor` depende de uma abstração, não de uma implementação específica. Em produção, o verificador pode usar HTTP, ICMP ou uma API de observabilidade; em testes, pode ser substituído por um objeto simulado. Esse desenho reduz acoplamento e facilita mudanças de tecnologia.

Boas práticas para começar

1. Modele o problema antes de criar classes.
2. Dê nomes que expressem responsabilidades reais.
3. Prefira classes pequenas e coesas.
4. Encapsule estado mutável e valide invariantes.
5. Prefira composição e interfaces a heranças profundas.
6. Escreva testes para regras de negócio e falhas relevantes.
7. Use controle de dependências, como Maven ou Gradle, em vez de copiar arquivos `.jar` manualmente.
8. Registre versão do JDK, sistema operacional, arquitetura e parâmetros de execução.
9. Automatize compilação, testes, análise estática e verificação de vulnerabilidades no pipeline.
10. Escolha uma versão LTS compatível com o suporte da aplicação, não apenas a versão mais nova.

Conclusão

Aprender POO em Java continua relevante para quem desenvolve aplicações e para quem administra a infraestrutura que as executa. O valor não está em decorar quatro pilares, mas em entender responsabilidades, contratos, memória, concorrência e os efeitos operacionais de cada decisão.

Desde a aula original, Java deixou de ser uma plataforma associada a applets e versões isoladas. Hoje existe um ciclo de lançamentos previsível, versões LTS, JVMs altamente otimizadas, records, virtual threads e um ecossistema corporativo que evoluiu para Jakarta EE. Com esses fundamentos, profissionais de redes e infraestrutura conseguem avaliar melhor consumo de recursos, portabilidade, observabilidade e riscos de implantação.

Referências

• ECLIPSE FOUNDATION. **Jakarta EE Platform 11**. 2025. Disponível em: [https://jakarta.ee/specifications/platform/11/](https://jakarta.ee/specifications/platform/11/). Acesso em: 3 out. 2026.
• ECLIPSE FOUNDATION. **Jakarta EE 11 Release**. 2025. Disponível em: [https://jakarta.ee/release/11/](https://jakarta.ee/release/11/). Acesso em: 3 out. 2026.
• ORACLE. **Oracle Releases Java 25**. 16 set. 2025. Disponível em: [https://www.oracle.com/news/announcement/oracle-releases-java-25-2025-09-16/](https://www.oracle.com/news/announcement/oracle-releases-java-25-2025-09-16/). Acesso em: 3 out. 2026.
• ORACLE. **Java Platform, Standard Edition Documentation**. 2026. Disponível em: [https://docs.oracle.com/en/java/javase/](https://docs.oracle.com/en/java/javase/). Acesso em: 3 out. 2026.
• ORACLE. **Java Virtual Machine Guide, Release 24**. mar. 2025. Disponível em: [https://docs.oracle.com/en/java/javase/24/vm/](https://docs.oracle.com/en/java/javase/24/vm/). Acesso em: 3 out. 2026.
• OPENJDK. **JEP 444: Virtual Threads**. 2023. Disponível em: [https://openjdk.org/jeps/444](https://openjdk.org/jeps/444). Acesso em: 3 out. 2026.
• OPENJDK. **JEP 395: Records**. 2021. Disponível em: [https://openjdk.org/jeps/395](https://openjdk.org/jeps/395). Acesso em: 3 out. 2026.

*Artigo elaborado a partir do material “POO1 – Introdução”, versão original de 2017, com atualização conceitual e tecnológica para publicação na DIO.*