Padrões de Projeto em Java: não apenas um item no currículo

Padrões de Projeto em Java: não apenas um item no currículo

Todo desenvolvedor Java já ouviu pelo menos uma vez a frase: "Use padrões de projeto". Mas muitas vezes isso soa como um mantra. Tipo, se você não usa Singleton ou Factory, é um programador ruim. Na verdade, os padrões de projeto em Java não são um dogma nem um elemento obrigatório de todo projeto. São uma ferramenta. E como qualquer ferramenta, devem ser aplicados no lugar certo.

Neste artigo, vamos entender para que servem os padrões, quando seu uso é justificado e quando é melhor escrever código simples sem firulas. E, claro, veremos exemplos práticos em Java.

O que são padrões de projeto e por que são importantes

Padrões de projeto são soluções comprovadas para problemas típicos. Não precisam ser inventados do zero. Eles nasceram da experiência de milhares de desenvolvedores. Quando você enfrenta um problema que alguém já resolveu antes, o padrão oferece um esquema pronto.

Mas há um detalhe. Os padrões de projeto em Java não existem no vácuo. Eles estão intimamente ligados aos princípios SOLID. Se você não entende por que uma interface é necessária ou para que separar a lógica em uma classe específica, os padrões não vão ajudar. Eles apenas formalizam esses princípios.

Quando aplicar padrões e quando não

A regra de ouro: o padrão é uma solução, não um objetivo. Não implemente um Abstract Factory só porque "é o que se faz". Pergunte a si mesmo:

\n
• Este padrão resolve meu problema atual?
\n
• Ele simplificará a manutenção do código no futuro?
\n
• Não dificultará o entendimento para novatos na equipe?
\n

Se a resposta for "sim" para todas as três, use-o sem medo. Se pelo menos uma for "não", talvez valha a pena buscar uma solução mais simples.

Quando os padrões são realmente necessários:

\n
• O código está crescendo e se tornando difícil de manter
\n
• É necessária flexibilidade: adicionar novas funcionalidades sem alterar as antigas
\n
• Trabalho em equipe: padrões são uma linguagem comum
\n

Principais padrões de projeto em Java com exemplos

Vamos analisar os quatro padrões mais populares do Gang of Four. Eles cobrem 80% dos problemas típicos.

1. Singleton: quando o objeto deve ser único

Propósito: Garantir que uma classe tenha apenas uma instância e fornecer um ponto de acesso global a ela.

Quando usar: Loggers, configurações, pools de conexão com banco de dados. Mas não abuse — o Singleton é frequentemente criticado por criar dependências ocultas.

Exemplo em Java:

public class DatabaseConnectionPool {\n    private static volatile DatabaseConnectionPool instance;\n    private final int maxConnections = 10;\n\n    private DatabaseConnectionPool() {\n        // construtor privado\n    }\n\n    public static DatabaseConnectionPool getInstance() {\n        if (instance == null) {\n            synchronized (DatabaseConnectionPool.class) {\n                if (instance == null) {\n                    instance = new DatabaseConnectionPool();\n                }\n            }\n        }\n        return instance;\n    }\n\n    public Connection getConnection() {\n        // lógica para obter conexão\n        return new Connection();\n    }\n}

Observe o uso de volatile e a dupla verificação. Este é um Singleton thread-safe. Sem isso, em um ambiente multithread, você pode obter duas instâncias diferentes.

2. Factory Method: delegando a criação de objetos

Propósito: Definir uma interface para criar um objeto, mas permitir que as subclasses alterem o tipo do objeto criado.

Quando usar: Quando não se sabe antecipadamente qual classe específica será necessária. Por exemplo, criação de diferentes tipos de documentos (PDF, Word, Excel).

Exemplo em Java:

// Interface do produto\ninterface Document {\n    void open