DEV Community: Breno Baudson

Singleton de forma simples

Breno Baudson — Wed, 30 Apr 2025 14:38:05 +0000

Singleton é um padrão criacional que garante uma única instância para um objeto, além de fornecer um ponto de acesso global para essa instância. Em outras palavras, o objeto será criado apenas uma vez em todo o processo.

Imagine que você está construindo um sistema para uma escola. Este sistema deverá viabilizar dentre outras funcionalidades, a matricula de alunos. Durante o processo de cadastro é necessário indicar o diretor vigente, que é único. Dentre várias possibilidades, o padrão Singleton tem o objetivo de solucionar este tipo de problema.

Vamos implementar um código na prática sem um padrão bem definido e com o Singleton. Acompanhe:

Sem Singleton

Classe Diretor com construtor publico (todos podem criar uma nova instância de diretor)

@Getter
public class Diretor {

    private String nome;
    private String sobrenome;

    public Diretor(String nome, String sobrenome) {
        this.nome = nome;
        this.sobrenome = sobrenome;
    }    
}

Sempre que diretor for instânciado, um novo objeto será criado (new Diretor)

public class Main {
    public static void main(String[] args) {

        Diretor diretor = new Diretor("josé", "Silva");
        System.out.println("Nome:" + diretor.getNome());
        System.out.println(diretor);

        Diretor outroDiretor = new Diretor("josé", "Silva");
        System.out.println("Nome:" + outroDiretor.getNome());
        System.out.println(outroDiretor);
    }
}

Notem que são dois objetos diferentes. Imagine que um aluno foi matriculado e o diretor foi "José", um professor foi contratado e o diretor foi "joão". Cada ponto do sistema, um novo objeto sendo criado e possibilitando trocar o valor dos atributos. Isso pode causar decisões conflitantes, bugs e resultados não esperados. Por isso há a necessidade de criar um objeto único...

Com Singleton

Classe diretor criada, mas dessa vez com um construtor privado. Isso significa que apenas a classe diretor terá acesso ao próprio construtor. Ou seja, ninguém mais poderá criar um Diretor a não ser a própria classe.

@Getter
public class Diretor {
    private static Diretor instance;

    private String nome;
    private String sobrenome;

    private Diretor(String nome, String sobrenome) {
       this.nome = nome;
         this.sobrenome = sobrenome;
    }

    public static Diretor getInstance(String nome, String sobrenome) {
        if (instance == null) {
            instance = new Diretor(nome, sobrenome);
        }
        return instance;
    }

}

Agora a classe cliente deverá chamar o método getInstance() ao invés de new Diretor(..). O método por sua vez, devolverá sempre a mesma instância caso ela já exista.

public class Main {
    public static void main(String[] args) {

        Diretor diretor = Diretor.getInstance("joão", "Silva");
        System.out.println("Nome:" + diretor.getNome());
        System.out.println(diretor);

        Diretor outroDiretor = Diretor.getInstance("fulado", "de tal");
        System.out.println("Nome:" + outroDiretor.getNome());
        System.out.println(outroDiretor);
    }
}

Notem que agora, o objeto retornado sempre será o mesmo, pois foi instânciado apenas uma vez.

Como na maioria esmagadoras dos casos (quase me atrevo a dizer todos), esta não é a única forma de resolver este problema. Poderíamos usar, por exemplo, a injeção de dependências, deixando o código um pouco mais fácil de manter e testar. Entretanto, o intuito é avaliar este padrão em específico, como implementa-lo, quais suas vantagens e desvantagens.

Existem diversos outros exemplos de implementação do padrão Singleton. Dentre os mais famosos, temos:

gerenciamento de configurações de sistemas. Exemplo: o Singleton ser a classe responsável por trocar o tema da IDE. Sempre teremos um único tema por vês e por isso o Singleton faz sentido.
gerenciamento de instâncias de banco de dados. Exemplo: ter um Singleton responsável por abrir uma conexão e mantê-la. Disponibilizando-a para quem precisar sem precisar abrir novas conexões, economizando recursos e otimizando performance.

Vantagens

Garantia de unicidade: garante que haja apenas um diretor na escola.
Acesso centralizado: permite que qualquer parte do sistema, como professores, alunos, secretários(...) acesse facilmente as informações e os métodos do diretor.
Controle de recursos: se o diretor precisar gerenciar recursos limitados, como vagas em turmas ou orçamento, o Singleton garante que ele tenha uma visão centralizada e evite conflitos.
Consistência: garante que todos os componentes do sistema estejam trabalhando com as mesmas informações e diretrizes do diretor.

Desvantagens

Responsabilidade única: viola o princípio da responsabilidade única pois a classe Singleton assume a responsabilidade de criar e gerenciar sua própria instância.
Aumenta complexidade de testar: dificulta a criação de testes unitários para as classes que dependem do diretor, pois é difícil substituir o Singleton por um "mock" ou "stub" durante os testes.
Acoplamento global: cria um acoplamento global entre a classe Diretor e as classes que a utilizam, tornando o código menos flexível e mais difícil de modificar.
Dificuldade de escalabilidade: pode dificultar a evolução do sistema, pois a dependência global do diretor pode tornar difícil a introdução de novas funcionalidades ou a modificação das existentes.

Entenda também

Abstract Factory na prática!

Breno Baudson — Wed, 23 Apr 2025 22:01:27 +0000

O Abstract Factory é um padrão de projeto do tipo criacional que oferece uma solução eficiente para criar uma família de objetos relacionados, sem especificar as classes concretas. Em outras palavras, ele permite criar grupos de objetos através de abstrações/ interfaces. Tudo isso, garantindo que os objetos sejam compatíveis entre si.

Imagine que você está desenvolvendo um sistema para uma escola e ela tenha diferentes níveis de ensino, como ensino fundamental e ensino médio. E que, cada nível precise de um conjunto específico de objetos relacionados como, alunos, professores e materiais didáticos. Esses objetos têm características distintas dependendo do nível de ensino. Por exemplo:

Alunos do fundamental podem ter atributos como "responsável legal" e alunos do ensino médio não terão este atributo.
Professores do ensino médio podem ter especializações específicas, ao contrário do ensino fundamental.
Materiais didáticos variam conforme o nível (livros infantis no fundamental e livros técnicos no Médio).

Com o Abstract Factory, podemos criar uma fábrica abstrata que terá métodos para criar as famílias dos objetos relacionados (aluno, professor e material didático). Cada implementação concreta da fábrica será responsável por criar objetos específicos para cada nível de ensino.

Façamos um comparativo entre uma implementação inicial sem padrão definido e uma com o padrão Abstract Factory.

Sem padrão definido

Criei uma classe para Pessoa. De forma que eu reaproveite código entre Aluno e Professor.

public class Pessoa {
    private String nome;
    private String sobrenome;
    private String email;

    public Pessoa(String nome, String sobrenome, String email) {
        this.nome = nome;
        this.sobrenome = sobrenome;
        this.email = email;
    }
}

Criei uma classe para Aluno, que terá o atributo responsavelLegal

@Getter
@Setter
public class Aluno extends Pessoa {

    private Pessoa responsavelLegal;

    public Aluno(String nome, String sobrenome, String email) {
        super(nome, sobrenome, email);
    }

}

Criei a classe Professor que terá mais dois atributos adicionais

@Getter
@Setter
public class Professor extends Pessoa {

    private String disciplina;
    private String especializacao;

    public Professor(String nome, String sobrenome, String email) {
        super(nome, sobrenome, email);
    }

}

Criei uma classe para MaterialDidatico

@Getter
@Setter
@AllArgsConstructor
public class MaterialDidatico {
    private String livro;
    private BigDecimal preco;
}

Desta forma, quando a classe cliente precisar matricular um aluno, deverá conhecer a implementação de cada objeto.

public class EscolaService {

    public void matricularAluno(){
        Pessoa responsavel = new Pessoa("responsavel", "legal", "email2");

        Aluno aluno = new Aluno("fulano","silva", "email1");
        aluno.setResponsavelLegal(responsavel);

        Professor professor = new Professor("professor", "silva", "email3");
        professor.setDisciplina("Geral");

        MaterialDidatico materialDidatico = new MaterialDidatico("livro I", new BigDecimal(100));

        ///restante da implementação

    }    
}

Esta prática, embora simples, pode tornar a classe cliente extremamente grande, complexa, acoplada, difícil de manter, entender e escalar.
Por outro lado, a implementação do Abstract Factory nesse exemplo pode resolver todos estes problemas. Acompanhe...:

Com Abstract Factory

Criei uma interface para criar os objetos

public interface EnsinoFactory {

    Aluno criarAluno(String nome, String sobrenome, String email, String responsavel);

    Professor criarProfessor(String nome, String sobrenome, String email, String disciplina, String especializacao);

    MaterialDidatico criarMaterialDidatico();
}

E uma classe concreta para o ensino fundamental. Aqui, implementei uma regra exigindo que o responsável legal seja populado para o Aluno e ignorei a especialização do professor. Por outro lado, o material didático já possui suas próprias regras, desprezando parâmetros de entrada.

public class EnsinoFundamentalFactory implements EnsinoFactory {

    @Override
    public Aluno criarAluno(String nome, String sobrenome, String email, String responsavel) {
        if (responsavel == null || responsavel.isEmpty()) {
            throw new IllegalArgumentException("Responsável não pode ser nulo ou vazio");
        }
        return new Aluno(nome, sobrenome, email, responsavel);
    }

    @Override
    public Professor criarProfessor(String nome, String sobrenome, String email, String disciplina, String especializacao) {
        return new Professor(nome, sobrenome, email);
    }

    @Override
    public MaterialDidatico criarMaterialDidatico() {
        return new MaterialDidatico("Livro Infantil I", new BigDecimal("100.00"));
    }
}

O mesmo sobre a classe concreta do ensino médio. Aqui garanti que a especialização do professor seja informada. Desconsiderei o responsável do aluno e já criei o material didático com suas especificidades.

 public class EnsinoMedioFactory implements EnsinoFactory {

    @Override
    public Aluno criarAluno(String nome, String sobrenome, String email, String responsavel) {
        return new Aluno(nome, sobrenome, email);
    }

    @Override
    public Professor criarProfessor(String nome, String sobrenome, String email, String disciplina, String especializacao) {
        if (especializacao == null || especializacao.isEmpty()) {
            throw new IllegalArgumentException("Especialização não pode ser nula ou vazia");
        }
        if (disciplina == null || disciplina.isEmpty()) {
            throw new IllegalArgumentException("Disciplina não pode ser nula ou vazia");
        }
        return new Professor(nome, sobrenome, email, disciplina, especializacao);
    }

    @Override
    public MaterialDidatico criarMaterialDidatico() {
        return new MaterialDidatico("Material de Ensino Médio", new BigDecimal("150.00"));
    }
}

Agora, a classe cliente chamará a factory e terá acesso aos métodos em específico

public class EscolaService {

    EnsinoFactory factoryFundamental = new EnsinoFundamentalFactory();
    EnsinoFactory factoryMedio = new EnsinoMedioFactory();

    public void matricularAluno(){
        //Criando um aluno do ensino fundamental
        Aluno aluno = factoryFundamental.criarAluno("josé","Silva","j@email.com","Maria");
        Professor professor = factoryFundamental.criarProfessor("Mauricio", "Souza", "prof@email",null, null);
        MaterialDidatico materialDidatico = factoryFundamental.criarMaterialDidatico();

        //Criando um aluno do ensino médio
        Aluno alunoMedio = factoryMedio.criarAluno("Bia","Carvalho","bia@email.com",null);
        Professor professorMedio = factoryMedio.criarProfessor("Ana", "Lima", "prof@email","Portugues", "Literatura");
        MaterialDidatico materialDidaticoMedio = factoryMedio.criarMaterialDidatico();
        ///Restante do código
    }
}

Agora você pode estar pensando se valeu a pena, não é mesmo!?
Suponhamos que amanhã surja o ensino técnico, e ele tenha suas próprias regras. Com esta implementação, fica fácil criar uma implementação nova para ele sem alterar as demais. Desta forma, deixamos as regras separadas por cada tipo de matrícula, diminuímos a quantidade de código na classe cliente e, com isso, baixamos a complexidade, risco de bugs e aumentamos a facilidade em manter, entender e escalar o código.

Dá pra fazer diferente?

Como em todos os padrões, a implementação pode variar em cima das necessidades. A ideia é ajudar, mas nunca, engessar.

Neste exemplo poderíamos ainda, criar interfaces para Aluno e Professor. Apesar de incrementar mais classes, isso deixaria o código ainda mais desacoplado e fácil de manter.

public interface Aluno {
String getNome();
// outros métodos comuns
}

public class AlunoFundamental implements Aluno { ... }
public class AlunoMedio implements Aluno { ... }

Outro ajuste seria utilizar a sobrecarga de métodos na interface EnsinoFactory. Ao invés de termos um método criarAluno() com todos os parâmetros, poderíamos ter dois. Um com os parâmetros do fundamental e outro com os parâmetros do médio. Desta forma não precisaríamos passar parâmetros desnecessários da classe cliente.

public interface EnsinoFactory {
  Aluno criarAluno(String nome, String sobrenome, String email, String responsavelLegal); // Fundamental
  Aluno criarAluno(String nome, String sobrenome, String email); // Médio

Uma terceira possibilidade seria criar uma classe "Matricula", que recebesse Aluno, Professor e Matricula. Depois retornar este objeto em cada factory. Desta forma, ao criar uma matricula os 3 objetos sempre seriam retornados juntos.

Veja que, existem diversas formas de se pensar e mesmo assim se basear no mesmo padrão. Tudo depende do contexto e necessidade de cada cenário.

Vantagens

Desacoplamento: o cliente trabalha apenas com interfaces/abstrações, sem conhecer as classes concretas dos produtos.

Centralização das regras de negócio: as regras específicas de cada família ficam encapsuladas nas fábricas concretas, facilitando manutenção e evolução.

Facilidade para adicionar novas famílias: para implementar uma nova variação como o Ensino Técnico, por exemplo, basta criar uma nova fábrica concreta e suas implementações, sem alterar código existente (princípio Open/Closed).

Testes: facilita a criação dos testes unitários, pois é possível injetar diferentes fábricas em cenários de teste.

Desvantagens

Complexidade: aumenta o número de classes no projeto, principalmente se houver muitas famílias.

Custo: Se as diferenças entre famílias forem mínimas, pode ser um “overkill” usar o padrão, pois demanda maior esforço para implementa-lo.

Tiro pela culatra: se precisar adicionar um novo tipo de objeto à família, como coordenador por exemplo, será necessário modificar todas as fábricas abstratas e concretas, violando o princípio Open/Closed nesse aspecto.

Curva de aprendizado: pode ser mais difícil de entender a princípio.

Entenda também

Desmistificando o Factory Method

Breno Baudson — Wed, 09 Apr 2025 22:47:13 +0000

O Factory Method (ou Método de Fábrica) é um padrão de projeto do tipo criacional que oferece uma solução elegante para a criação de objetos em sistemas complexos.

Imagine que você está desenvolvendo um sistema para uma escola que precisa gerenciar alunos, professores e prestadores de serviço, cada um com atributos e comportamentos distintos. Sem um padrão adequado, a criação desses objetos pode se tornar confusa e enrolada como um prato de miojo frio, especialmente se a lógica de criação estiver espalhada por todo o código. O Factory Method visa resolver esses problemas, definindo uma interface para criar os objetos, promovendo desacoplamento, flexibilidade, facilidade de manutenção e adição de novos tipos de objetos no futuro.

Façamos um comparativo entre uma implementação inicial sem padrão definido e uma com o padrão Factory.

Sem padrão definido

Criei a classe que representa Aluno

public class Aluno {
    String nome;
    String sobrenome;
    Long matricula;
}

Criei uma classe Professor

public class Professor {
    String nome;
    String Sobrenome;
    BigDecimal salario;
}

A classe cliente, ao precisar instanciar Aluno e/ou professor precisa conhecer a implementação de cada uma...

public class ServicoPessoa {

    Aluno aluno = new Aluno("Lucas", "Silva", 123456L);
    Professor professor = new Professor("Maria", "Oliveira", new BigDecimal(5000));

    ///// Restante da implementação
}

Por enquanto é uma implementação padrão e comum, não representa riscos não é mesmo!?
Porém, ainda não criamos a classe para Prestadores de Serviço, que podem se dividir em várias outras como serviço de limpeza, manutenção de equipamentos e etc. A implementação traz repetição de código, acoplamento e riscos para o código.
Imaginemos que, a partir de agora todas as pessoas terão mais um atributo para e-mail. Já temos duas classes para refatorar. Imagine ainda que, teremos mais uma classe de funcionários, que terá os mesmos campos e mais atributos específicos. Olhando por este lado, começamos a encontrar potenciais problemas.

Pois bem, vamos refatorar este esqueleto e implementar o tal falado Factory.

Implementando Factory

Uma boa ideia seria criarmos um contrato com os atributos principais, fazendo com que eles não se repitam...

public abstract class Pessoa {
    String nome;
    String sobrenome;
    String email;

    public Pessoa(String nome, String sobrenome, String email) {
        this.nome = nome;
        this.sobrenome = sobrenome;
        this.email = email;
    }

    public Pessoa() {
        // Construtor padrão (sem argumentos)
    }

A partir daqui, as outras classes extenderem a pessoa, herdarão os atributos comuns e declararão apenas os inerentes a cada uma.

public class Aluno extends Pessoa {
    Long matricula;

    public Aluno(String nome, String sobrenome, String email) {
        super(nome, sobrenome, email); // Chama o construtor da classe Pessoa   
    }

    public Aluno() {
        // Construtor padrão (sem argumentos)
    }
}

public class Professor extends Pessoa {
    BigDecimal salario;

    public Professor(String nome, String sobrenome, String email) {
        super(nome, sobrenome, email); // Chama o construtor de Pessoa        
    }

    public Professor() {
    }
}

Com este primeiro passo já eliminamos a repetição de código e começamos a centralizar a lógica, mas podemos ir além..
Com esta refatoração, o cliente ainda precisa conhecer as classe Aluno e Professor para instancia-las. É agora que implementamos o padrão Factory!

Digamos que o nosso intuito inicial seja apenas criar um objeto de pessoa, para isso, iniciei criando uma interface de um factory central, que vai gerenciar a criação dos objetos.

public interface PessoaFactory {
Pessoa criarPessoa(String tipo, String nome, String sobrenome, String email);
}

Agora crio a implementação desta interface

public class PessoaFactoryManeger implements PessoaFactory {

    @Override
    public Pessoa criarPessoa(String tipo, String nome, String sobrenome, String email) {
        if (tipo.equalsIgnoreCase("aluno")) {
            return new Aluno(nome, sobrenome, email);
        } else if (tipo.equalsIgnoreCase("professor")) {
            return new Professor(nome, sobrenome, email);
        }
        return null;
    }

}

Desta forma, as subclasses não precisam conhecer a implementação de Aluno nem Professor. Basta chamar a factory.

public class ServicoPessoa {
    PessoaFactory factory = new PessoaFactory();

    public void criarPessoas() {        
        Pessoa aluno = factory.criarPessoa("aluno", "João", "Silva", "joao.silva@email.com");
        Pessoa professor = factory.criarPessoa("professor", "Maria", "Souza", "maria.souza@email.com");
        //demais implementações, como inserir a nota do aluno, etc.
    }
}

Este é um exemplo mais simples para entendermos a ideia, porém temos várias possibilidades, como:

Criar métodos específicos em PessoaFactory, para criar um Professor, por exemplo. Ele já receberia o valor doa tributo salário. Exemplo:

public interface PessoaFactory {
    Pessoa criarPessoa(String tipo, String nome, String sobrenome, String email);

    Professor criarProfessor(String nome, String sobrenome, String email, BigDecimal salario);  

    Aluno criarAluno(String nome, String sobrenome, String email, Long matricula);
}

Criar factory especifica para cada tipo de pessoa e delegar as responsabilidades para cada uma. Desta forma, a responsabilidade da PessoaFactoryManeger será apenas decidir qual outra factory chamar. Exemplo:

public class AlunoFactory implements PessoaFactory {
@Override
public Pessoa criarPessoa(String nome, String sobrenome, String email, Long matricula) {
    return new Aluno(nome, sobrenome, email, matricula);
}
}

Estas são possibilidades que, apesar de serem mais trabalhosas na implementação inicial, diminuem muito a complexidade de manutenção, promovem desacoplamento, facilitam implementações de novas implementações de pessoas, proporcionam simplicidade em inserir novos atributos e comportamentos nas classes principais.

Vantagens do Factory Method:

Desacoplamento: desacoplou o código do cliente (que usa os objetos) das classes concretas que implementam esses objetos. O cliente interage apenas com a interface, sem precisar conhecer os detalhes de implementação das classes concretas. Isso deixa o código flexível e fácil de manter.

Flexibilidade: permitiu adicionar novas pessoas sem alterar o código "base". Desta forma fica muito mais fácil adaptar novas necessidades.

Encapsulamento: a utilização do padrão centralizou a lógica de criação dos objetos na fábrica. Facilitou a manutenção e evitou duplicação de código.

Responsabilidade única: cada fabrica foi se tornou responsável por criar um tipo especifico de objeto. Esse comportamento segue o principio de responsabilidade única, deixando o código mais modular e fácil de testar.

Extração de complexidade: caso haja complexidade na criação dos objetos, o cliente não precisa ter este conhecimento.

Desvantagens

Aumento da complexidade inicial: pode aumentar a complexidade inicial do código, principalmente se você tem muitos tipos de objetos para criar.

Procriação das classes: as classes podem se procriar como coelhos, principalmente se usarmos uma factory para cara objeto. Isso pode tornar o código mais difícil de navegar e entender.

Overkill / Exagero: em sistemas simples, o padrão Factory pode ser um exagero e aumentar complexidade ao invés de diminuir. Exemplo: se você tem apenas um ou poucos objetos, e não tem previsão de adicionar novos tipos no futuro.

Custo: embora o Factory facilite a manutenção a longo prazo, ele pode aumentar o custo inicial de manutenção, já que a criação das interfaces e classes de fábrica exigem tempo e esforço.

Considerações finais

Os padrões são poderosos e podem trazer muitos benefícios para os sistemas. No entanto, é importante avaliar as vantagens e desvantagens antes de usa-los. Em sistemas simples, o Factory Method pode ser um exagero, porém, em sistemas complexos ele pode ser um aliado valioso.