DEV Community: Maximillian Arruda

Facilite a vida de quem utiliza seus códigos: construindo Builders inteligentes

Maximillian Arruda — Mon, 06 Jan 2025 12:30:00 +0000

Costumamos a ouvir "Facilite a vida do seu cliente". Mas, e quanto aos desenvolvedores que vão trabalhar com o código que você escreve? Com certeza é importante facilitar a vida deles também.

Independente do cliente alvo da sua solução, você estará criando código que será mantido por outros desenvolvedores incluindo você também muitas vezes. Escolher boas abordagens e técnicas irá facilitar a vida deles ou a sua vida provavelmente. Ser um desenvolvedor eficaz não é apenas sobre escrever código que funcione, mas também sobre escrever código que seja fácil de ler, de entender e de manter.

O tema sobre boas práticas e técnicas é muito extenso e, eu não estou aqui para dizer o que você deve ou não fazer. Eu acredito que a melhor abordagem depende do contexto.

Neste conteúdo, vamos discutir como facilitar a vida dos desenvolvedores usando boas estratégias para construir objetos complexos.

O cenário: O objeto complexo

Uma boa maneira de aprender coisas é através de exemplos. Então, aqui está o nosso desafio:

Precisamos criar um objeto Notification que tenha os seguintes atributos obrigatórios:

title: o título da notificação;
message: o conteúdo da notificação;
recipient: a pessoa que receberá a notificação;

e os atributos opcionais:

highPriority: uma flag para indicar se a notificação é de alta prioridade. O padrão é false;
type: o tipo da notificação. Uma enumeração com os seguintes valores suportados: GENERAL, INFO, WARNING, ERROR. O padrão é Type.GENERAL;
attachment: um texto com o caminho para o arquivo de anexo. O padrão é null;

Abaixo, segue mais requisitos que precisamos atender:

title: é obrigatório e não pode ser nulo;
message: é obrigatório e não pode ser nulo;
recipient: é obrigatório e não pode ser nulo;
highPriority: é opcional, mas não pode ser nulo;
type: é opcional, mas não pode ser nulo;

Temos aqui uma inicial definição para nossa classe Notification:

public class Notification {

    private String title; // mandatory
    private String message; // mandatory
    private String recipient; // mandatory
    private boolean isHighPriority; // optional
    private Type type; // optional
    private String attachment; // optional

    public static enum Type {
        GENERAL, INFO, WARNING, ERROR
    }

    // omitted getters
}

Alguns desenvolvedores poderiam argumentar: "Podemos usar o construtor padrão e os setters para definir os atributos opcionais". Bom, vamos tentar seguir este argumento:

import java.util.Optional;

import static java.util.Optional.ofNullable;
import static java.util.Objects.requireNonNull;

public class Notification {

    private String title; // mandatory
    private String message; // mandatory
    private String recipient; // mandatory
    private boolean highPriority; // optional
    private Type type = Type.GENERAL; // optional
    private String attachment; // optional

    public static enum Type {
        GENERAL, INFO, WARNING, ERROR
    }

    public void setTitle(String title) {
        this.title = requireNonNull(title, "title is required");
    }

    public String getTitle() {
        return title;
    }

    public void setMessage(String message) {
        this.message = requireNonNull(message, "message is required");
    }

    public String getMessage() {
        return message;
    }

    public void setRecipient(String recipient) {
        this.recipient = requireNonNull(recipient, "recipient is required");
    }

    public String getRecipient() {
        return recipient;
    }

    public void setHighPriority(boolean highPriority) {
        this.highPriority = highPriority;
    }

    public boolean isHighPriority() {
        return highPriority;
    }

    public void setType(Type type) {
        this.type = type;
    }

    public Optional<Type> getType() {
        return ofNullable(type);
    }

    public void setAttachment(String attachment) {
        this.attachment = attachment;
    }

    public  Optional<String> getAttachment() {
        return attachment;
    }

    // omitted hash and equals methods 
}

Analisando o código acima, podemos ver que o desenvolvedor deve chamar os setters para definir os atributos. O código para criar um objeto Notification provavelmente seria assim:

public class NotificationProgram {

    public static void main(String[] args) {
        Notification notification = new Notification();
        notification.setTitle("New message");
        notification.setMessage("Hello, world!");
        notification.setRecipient("johndoe@system.com");
        notification.setHighPriority(true);
        notification.setType(Notification.Type.INFO);
        notification.setAttachment("/path/to/attachment.txt");
    }
}

No código acima, podemos destacar algumas desvantagens e problemas com essa abordagem:

Objetos Notification podem ser instanciados com estado inválido: as restrições do nosso desafio estão sendo violadas.
Objetos Notification não são thread-safe: os setters podem ser chamados por múltiplas threads ao mesmo tempo, causando problemas de condições de corrida (race conditions), um problema muito comum que podem ocorrer em aplicações multithreaded.
Os desenvolvedores devem chamar os setters para definir tanto os atributos obrigatórios quanto os opcionais: é um processo um tanto verboso e propenso a erros porque o desenvolvedor pode esquecer de definir algum de seus atributos, fazendo com que o objeto entre em um estado inválido;
Não está claro como o objeto deve ser criado: o desenvolvedor deverá ler a documentação para saber quais atributos são obrigatórios e quais são opcionais para assim poder defini-los;

Mas também, podemos destacar algumas coisas boas nesta abordagem: os desenvolvedores podem chamar os setters dos atributos opcionais conforme necessário, dando muita flexibilidade na utilização.

Dados os problemas acima, vamos tentar endereçá-los:

Objetos Notification podem ser instanciados com estado inválido: as restrições do nosso desafio estão sendo violadas.

Okay, você poderia dizer: "Não é um grande problema! Podemos usar o construtor para definir os atributos obrigatórios e os setters para definir os atributos opcionais". Vamos tentar seguir este argumento:

import static java.util.Optional.ofNullable;
import static java.util.Objects.requireNonNull;

public class Notification {

    private String title; // mandatory
    private String message; // mandatory
    private String recipient; // mandatory
    private boolean highPriority; // optional
    private Type type = Type.GENERAL; // optional
    private String attachment; // optional

    public static enum Type {
        GENERAL, INFO, WARNING, ERROR
    }

    public Notification(String title, String message, String recipient) {
        setTitle(title);
        setMessage(message);
        setRecipient(recipient);
    }

    public void setTitle(String title) {
        this.title = requireNonNull(title, "title is required");
    }

    public String getTitle() {
        return title;
    }

    public void setMessage(String message) {
        this.message = requireNonNull(message, "message is required");
    }

    public String getMessage() {
        return message;
    }

    public void setRecipient(String recipient) {
        this.recipient = requireNonNull(recipient, "recipient is required");
    }

    public String getRecipient() {
        return recipient;
    }

    public void setHighPriority(boolean highPriority) {
        this.highPriority = highPriority;
    }

    public boolean isHighPriority() {
        return highPriority;
    }

    public void setType(Type type) {
        this.type = type;
    }

    public Optional<Type> getType() {
        return ofNullable(type);
    }

    public void setAttachment(String attachment) {
        this.attachment = attachment;
    }

    public  Optional<String> getAttachment() {
        return attachment;
    }

    // omitted hash and equals methods 
}

Vamos atualizar o NotificationProgram que cria um objeto Notification:

public class NotificationProgram {

    public static void main(String[] args) {
        Notification notification = new Notification("New message", "Hello, world!", "johndoe@system.com");
        notification.setHighPriority(true);
        notification.setType(Notification.Type.INFO);
        notification.setAttachment("/path/to/attachment.txt");
    }
}

Aparentemente resolvemos o primeiro problema, certo? Bem, vamos analisar o código novamente:

Com as mudanças os objetos Notification serão instanciados com referências não nulas para os atributos obrigatórios. Mas, ainda temos alguns problemas: o construtor Notification com todos os atributos obrigatórios é propenso a erros! Agora, os desenvolvedores podem definir os atributos na ordem errada. Por exemplo, o desenvolvedor pode definir o recipient antes do title, o que invalida o estado do objeto fazendo com que os campos contenham o valor errado. Tal problema só poderá ser detectado em um processo de depuração ou analisando a saída derivada desses objetos Notification inválidos.

Talvez dois ou três argumentos com o mesmo tipo não seja um grande problema, mas na perspectiva dos desenvolvedores que irão usar nossa classe, não é algo fácil de lidar, e se tivermos mais atributos? O construtor se tornará ainda mais complexo e propenso a erros.

Vamos continuar, mas agora tentando resolver o segundo problema:

Objetos Notification não são thread-safe: os setters podem ser chamados por múltiplas threads ao mesmo tempo, causando problemas de condições de corrida (race conditions), um problema muito comum que podem ocorrer em aplicações multithreaded.

A forma mais fácil de tornar os objetos Notification thread-safe é tornar os getters e setters synchronized usando Locks do pacote java.util.concurrent.locks. Isso funcionaria, mas tem algumas desvantagens que precisamos considerar:

Não é escalável e propenso a erros: quando for necessário adicionar mais atributos, os desenvolvedores devem garantir que qualquer estado de escrita e leitura será synchronized, o que pode levar a problemas de desempenho e deadlock de threads indesejados;
É uma abordagem verbosa: o desenvolvedor deve escrever muito código para tornar o objeto thread-safe.
Não é eficiente: sincronizar o acesso para ler e escrever dados pode causar problemas de desempenho em aplicações multithreaded.
Não temos clareza sobre como o objeto deve ser criado: o desenvolvedor deve ler a documentação para saber quais atributos são obrigatórios e quais são opcionais para assim poder defini-los;

Todas essas preocupações são necessárias apenas pelo fato que essa classe é base para instâncias de objetos mutáveis. Se o seu cenário requer objetos mutáveis, então faz sentido colocar esforço para lidar com todas essas preocupações. Caso contrário, se o seu cenário permitir que você use objetos imutáveis, então você pode evitar todas essas preocupações.

Por esse motivo precisamos ter clareza sobre os requisitos da sua solução antes de começar a codificar. Isso ajudará você a escolher a melhor abordagem para resolver o problema. Vamos voltar para a nossa classe Notification e tentar torná-la imutável.

Objetos imutáveis são seguros para threads por natureza porque não podem ser modificados após a criação. É uma boa prática tornar seus objetos imutáveis sempre que possível.

Podemos então usar construtores específicos para tornar o objeto Notification imutável. Veja abaixo:

import static java.util.Optional.ofNullable;
import static java.util.Objects.requireNonNull;

public class Notification {

    private final String title; // mandatory
    private final String message; // mandatory
    private final String recipient; // mandatory
    private final boolean highPriority; // optional
    private final Type type; // optional
    private final String attachment; // optional

    public static enum Type {
        GENERAL, INFO, WARNING, ERROR
    }

    public Notification(String title,
                        String message,
                        String recipient,
                        boolean highPriority,
                        Type type,
                        String attachment) {
        this.title = requireNonNull(title, "title is required");
        this.message = requireNonNull(message, "message is required");
        this.recipient = requireNonNull(recipient, "recipient is required");
        this.highPriority = highPriority;
        this.type = ofNullable(type).orElse(Type.GENERAL);
        this.attachment = attachment;
    }

    public String getTitle() {
        return title;
    }

    public String getMessage() {
        return message;
    }

    public String getRecipient() {
        return recipient;
    }

    public boolean isHighPriority() {
        return highPriority;
    }

    public Optional<Type> getType() {
        return ofNullable(type);
    }

    public  Optional<String> getAttachment() {
        return attachment;
    }

    // omitted hash and equals methods 
}

Agora, vamos atualizar o NotificationProgram que cria um objeto Notification:

public class NotificationProgram {

    public static void main(String[] args) {
        Notification notification = new Notification(
                "New message",
                "Hello, world!",
                "johndoe@system.com",
                true,
                Notification.Type.INFO,
                "/path/to/attachment.txt");
    }
}

Agora os objetos Notification são imutáveis e seguros para threads. O desenvolvedor pode instanciar o objeto com todos os atributos obrigatórios e opcionais em uma única linha de código. O objeto será criado em um estado válido, e o desenvolvedor não pode alterar seu estado após a criação.

Desde o Java 16, podemos usar a palavra-chave record para criar objetos imutáveis, é o que chamamos Java Records. Se você estiver usando o Java 16 ou superior, eu recomendo fortemente que você use Java Records para criar objetos imutáveis. Vamos ver como podemos refatorar a classe Notification para se tornar um Java Record:

import static java.util.Objects.requireNonNull;
import static java.util.Optional.ofNullable;

public record Notification(
        String title,
        String message,
        String recipient,
        boolean highPriority,
        Type type,
        String attachment) {

    public static enum Type {
        GENERAL, INFO, WARNING, ERROR
    }

    public Notification {
        requireNonNull(title, "title is required");
        requireNonNull(message, "message is required");
        requireNonNull(recipient, "recipient is required");
        type = ofNullable(type).orElse(Type.GENERAL);
    }
}

Menos código, mais legibilidade e mais manutenível. Esse é o poder dos Java Records.

Voltando para nosso desafio, algo ainda não está certo: se highPriority, type e attachment são atributos opcionais, por que é necessário fornecer cada valor no construtor?

Podemos resolver esse problema usando uma abordagem tradicional chamada Telescoping constructors.

Uma abordagem tradicional: Telescoping constructors

A common approach to object creation is to provide multiple constructors with different numbers of parameters. Each constructor calls application constructor with the required parameters and sets the optional parameters to default values. It's called telescoping constructors. You can use this approach on any java class, including Java Records.

Uma abordagem comum para a criação de objetos é fornecer vários construtores com diferentes números ou tipos de parâmetros. Cada construtor chama o construtor de aplicação com os parâmetros obrigatórios e define os parâmetros opcionais com valores padrão. Isso é o que chamamos de telescoping constructors (não encontrei nome em português aqui... se vc souber, mande nos comentários!). Você pode usar essa abordagem em qualquer classe Java, incluindo Java Records.

Vamos ver como ficará nossa classe utilizando essa abordagem:

import static java.util.Objects.requireNonNull;
import static java.util.Optional.ofNullable;

public record Notification(
        String title,
        String message,
        String recipient,
        boolean highPriority,
        Type type,
        String attachment) {

    public static enum Type {
        GENERAL, INFO, WARNING, ERROR
    }

    public Notification (String title, String message, String recipient) {
        this(title, message, recipient, false, Type.GENERAL, null);
    }

    public Notification {
        requireNonNull(title, "title is required");
        requireNonNull(message, "message is required");
        requireNonNull(recipient, "recipient is required");
        type = ofNullable(type).orElse(Type.GENERAL);
    }
}

Agora, os desenvolvedores poderão criar objetos Notification com apenas os atributos obrigatórios. Os atributos opcionais serão definidos com valores padrão. Lembrando que objetos Notification continuam sendo imutáveis e seguros para threads.

Vamos atualizar o NotificationProgram que cria um objeto Notification:

public class NotificationProgram {

    public static void main(String[] args) {
        var notificationWithDefaultOptionalValues =
                new Notification(
                        "New message", 
                        "Hello, world!", 
                        "johndoe@system.com");

        var notificationWithCustomOptionalValues =
                new Notification(
                        "Another message",
                        "Oh no! Something wrong happened",
                        "johndoe@system.com",
                        true,
                        Notification.Type.ERROR,
                        "/path/to/attachment.txt");
    }
}

Ótimo! Vamos revisar os problemas que tivemos e como os resolvemos:

Objetos Notification somente podem ser instanciados com estado válido: os construtores garantem que o objeto será criado em um estado válido;
Objetos Notification são imutáveis e seguros para threads: a imutabilidade garante que os objetos Notification são seguros para threads;

Bom, o terceiro problema sobre a verbosidade e propensão a erros dos construtores ainda existem. Quanto ao quarto item, podemos prover uma documentação que ajudará os desenvolvedores a saber qual construtor deve ser usado com a ordem dos argumentos. Mas nesse ponto, acredito que podemos fazer mais para facilitar a vida do desenvolvedor, não?

Favoreça Static Factory Methods ao invés de Construtores

Para ajudar os desenvolvedores a saber qual construtor deve ser usado, podemos fornecer métodos fábrica estáticos (Static Factory Methods) para criar objetos.

Static factory methods são métodos estáticos que retornam uma instância de uma determinada classe ou subclasse. Eles podem ter nomes que podém auxiliar quais os atributos que precisam ser fornecidos para criar um determinado objeto, facilitando assim a vida dos desenvolvedores a criar tais objetos.

Talvez você já tenha ouvido falar sobre o padrão "Factory Method" do livro Design Pattern (Gang of Four) antes, mas o Static Factory Method não é uma implementação direta desse padrão. O propósito pode até ser o mesmo, mas não há um padrão equivalente no livro Gang of Four para os Static Factory Methods, na verdade.

Algumas vantagens de usar métodos fábrica estáticos são:

Static factory methods tem nomes que descrevem o objeto que está sendo retornado: o desenvolvedor pode saber qual construtor deve ser usado lendo o nome do método;
Static factory methods não precisam criar um novo objeto em cada invocação: eles podem retornar o mesmo objeto se o objeto for imutável, economizando memória e recursos da CPU;
Static factory methods podem retornar qualquer objeto do tipo e/ou seus subtipos: eles podem retornar um objeto de um subtipo da classe, facilitando a criação de objetos com diferentes configurações.
Static factory methods podem retornar objetos tipo e seus subtipos dependendo dos argumentos de entrada fornecidos: diferentes dos construtores de uma classe que apenas retornam uma instância do seu tipo criando uma nova instância toda vez que são chamados, os métodos fábrica estáticos podem aplicar lógicas específicas e retornar objetos do tipo solicitado ou seus subtipos.

Antes de por nossos dedos no código, vamos pensar sobre como aplicar os métodos fábrica estáticos no nosso desafio. De acordo com o conceito de métodos fábrica estáticos, podemos criar um método fábrica estático para cada combinação de atributos. Isso até facilitará a vida do desenvolvedor, mas como devemos implementar esses métodos fábrica estáticos?

De fato, para nosso desafio, se concentrarmos em fornecer métodos fábrica estáticos para todas as combinações possíveis, resultaríamos em uma classe grande com muitos métodos fábrica estáticos. São cerca de 16 variações de métodos fábrica estáticos! Talvez não seja uma boa ideia ter muitos métodos fábrica estáticos em uma classe. Possivelmente isso irá tornar a classe mais difícil de entender e consequentemente de manter. Vamos mudar nosso ponto de vista: em vez de cobrir estaticamente todas as combinações possíveis, podemos fornecer métodos fábrica estáticos com os atributos permitindo assim realizar as possíveis combinações. Vamos ver como ficaria.

import static java.util.Objects.requireNonNull;
import static java.util.Optional.ofNullable;

@lombok.Builder
public record Notification(
        String title,
        String message,
        String recipient,
        boolean highPriority,
        Type type,
        String attachment) {

    public static enum Type {
        GENERAL, INFO, WARNING, ERROR;
    }

    public static Notification createNotification(Type type, String title, String message, String recipient) {
        return new Notification(title, message, recipient, false, type, null);
    }

    public static Notification createHighPriorityNotification(Type type, String title, String message, String recipient) {
        return new Notification(title, message, recipient, true, type, null);
    }

    public static Notification createNotificationWithAttachment(Type type, String title, String message, String recipient, String attachment) {
        return new Notification(title, message, recipient, false, type, attachment);
    }

    public static Notification createHighPriorityNotificationWithAttachment(Type type, String title, String message, String recipient, String attachment) {
        return new Notification(title, message, recipient, true, type, attachment);
    }

    public Notification {
        requireNonNull(title, "title is required");
        requireNonNull(message, "message is required");
        requireNonNull(recipient, "recipient is required");
        type = ofNullable(type).orElse(Type.GENERAL);
    }

}

Agora, desenvolvedores podem criar objetos Notification usando métodos fábrica estáticos. Os métodos fábrica estáticos têm nomes que descrevem quais os atributos que definiram o objeto que está sendo retornado, facilitando assim a vida dos desenvolvedores a saber qual construtor deve ser usado. E como estamos ainda utilizando Java Records, os objetos Notification continuam sendo imutáveis e seguros para threads.

Vamos atualizar o NotificationProgram que cria um objeto Notification:


public class NotificationProgram {

    public static void main(String[] args) {
        var generalNotificationWithoutAttachment = Notification
                .createNotification(
                        Notification.Type.GENERAL,
                        "General Notification",
                        "This is a general notification",
                        "johndoe@system.com");

        var highPrioryInfoNotification = Notification
                .createHighPriorityNotification(
                        Notification.Type.INFO,
                        "High Priority Info Notification",
                        "This is a high priority info notification",
                        "johndoe@system.com");
    }
}

Que legal! Estamos melhorando nosso código passo a passo. Talvez a forma como nossa classe foi implementada até o momento esteja okay para alguns casos, mas acredito que podemos fazer melhor!

Em nossa implementação, cada método fábrica estático está exigindo quatro argumentos. Não é um grande problema, mas e se tivermos mais atributos? Os métodos fábrica estáticos se tornarão ainda mais complexos e propensos a erros. Vamos ver como podemos resolver esse problema.

Muitos parâmetros? Use o padrão Builder

The Builder pattern is a creational design pattern that allows you to construct complex objects step by step. It's useful when you have many optional attributes in your class and you want to make the object creation more readable and maintainable.

O padrão Builder é um padrão de design criacional que permite construir objetos complexos passo a passo. É útil quando você tem muitos atributos em sua classe e deseja tornar a criação do objeto mais legível e manutenível.

Algumas biliotecas como Lombok, ou até plugins de IDEs como IntelliJ IDEA, podem gerar Builders para você. Isso é incrível, mas precisamos entender como ele funciona para poder usá-lo efetivamente.

Vamos ver como podemos implementar o padrão Builder para nossa classe Notification usando Lombok, por exemplo:

import lombok.Builder;
import static java.util.Objects.requireNonNull;
import static java.util.Optional.ofNullable;

@Builder
public record Notification(
        String title,
        String message,
        String recipient,
        boolean highPriority,
        Type type,
        String attachment) {

    public static enum Type {
        GENERAL, INFO, WARNING, ERROR;
    }

    public Notification {
        requireNonNull(title, "title is required");
        requireNonNull(message, "message is required");
        requireNonNull(recipient, "recipient is required");
        type = ofNullable(type).orElse(Type.GENERAL);
    }
}

Por baixos dos panos, o Lombok irá gerar para você todas as classes de builder para a classe Notification. No final, teremos um resultado similar ao abaixo:

import static java.util.Objects.requireNonNull;
import static java.util.Optional.ofNullable;

public record Notification(
        String title,
        String message,
        String recipient,
        boolean highPriority,
        Type type,
        String attachment) {

    public static NotificationDataBuilder builder() {
        return new NotificationDataBuilder();
    }

    public static enum Type {
        GENERAL, INFO, WARNING, ERROR;
    }

    public Notification {
        requireNonNull(title, "title is required");
        requireNonNull(message, "message is required");
        requireNonNull(recipient, "recipient is required");
        type = ofNullable(type).orElse(Type.GENERAL);
    }

    public static class NotificationDataBuilder {
        private String title;
        private String message;
        private String recipient;
        private boolean highPriority;
        private Type type;
        private String attachment;

        NotificationDataBuilder() {
        }

        public NotificationDataBuilder title(String title) {
            this.title = title;
            return this;
        }

        public NotificationDataBuilder message(String message) {
            this.message = message;
            return this;
        }

        public NotificationDataBuilder recipient(String recipient) {
            this.recipient = recipient;
            return this;
        }

        public NotificationDataBuilder highPriority(boolean highPriority) {
            this.highPriority = highPriority;
            return this;
        }

        public NotificationDataBuilder type(Type type) {
            this.type = type;
            return this;
        }

        public NotificationDataBuilder attachment(String attachment) {
            this.attachment = attachment;
            return this;
        }

        public Notification build() {
            return new Notification(title, message, recipient, highPriority, type, attachment);
        }
    }
}

O Lombok fornece muitas anotações para gerar código boilerplate para você. A anotação @Builder gera uma classe builder para a classe anotada. A classe builder gerada pelo Lombok tem uma interface fluente onde os desenvolvedores podem chamar de forma encadeada os métodos para definir os atributos da classe anotada e um método build() para criar uma instância da classe anotada.

Builders podem ser implementados de várias maneiras, como usando o estilo tradicional utilizando métodos setter, mas é comum implementá-los seguindo o estilo de design Fluent API.

O estilo de design Fluent API é enfatizado pela chamada encadeada de métodos. Ele permite que os desenvolvedores chamem métodos de forma encadeada, tornando o código mais legível e manutenível. É usado em muitas bibliotecas, frameworks e APIs para melhorar a experiência do desenvolvedor. Pode ser aplicado ao padrão Builder com certeza, mas não se limita a esse uso. Pode ser usado em DSLs (Domain-Specific Languages) e muitos outros contextos.

Particularmente eu prefiro ter essas classes explicitamente no meu código. Isso me ajuda a entender como o padrão Builder funciona e, o mais importante na minha opinião: ele libera os desenvolvedores de terem o Lombok configurado em suas IDEs. Uma dependência a menos para se configurar e se preocupar!

Vamos ver a flexibilidade que o padrão Builder fornece aos desenvolvedores:

public class NotificationProgram {
    public static void main(String[] args) {
        var generalNotification = Notification.builder()
                .title("Hello")
                .message("Hello World")
                .recipient("johndoe@system.com")
                .build();

        // do something with generalNotification

        var highPriorityInfoNotificationWithAttachment = Notification.builder()
                .title("Hello")
                .message("Hello World")
                .recipient("johndoe@system.com")
                .type(Type.INFO)
                .highPriority(true)
                .attachment("attachment.pdf")
                .build();

        // do something with highPriorityInfoNotificationWithAttachment;
    }
}

Agora, desenvolvedores poderão criar objetos Notification usando o padrão Builder. O padrão Builder permite que os desenvolvedores construam objetos complexos passo a passo, tornando a criação do objeto mais legível e manutenível.

Bom, tal builder como esses podem até ajudar facilitar a vida de alguns desenvolvedores, principalmente os desenvolvedores que estão criando o builder, mas e quanto aos desenvolvedores que irão usar o builder?

Mas o que você quer dizer com isso? - você pode perguntar. É essa é uma ótima pergunta!

Antes de adicionar a solução do builder na classe Notification, os desenvolvedores precisavam passar os argumentos obrigatórios para os métodos fábrica estáticos para criar objetos Notification. O compilador Java irá forçar o desenvolvedor a passar os argumentos obrigatórios e necessários para os métodos fábrica estáticos para criar objetos Notification com estado válido. A solução builder que adicionamos a nossa classe não fornece essa capacidade de maneira padrão. Veja o código abaixo:

public class NotificationProgram {
    public static void main(String[] args) {
        var anotherNotification = Notification.builder()
                .recipient("johndoe@system.com")
                .build();
    }
}

Você pode dizer: "Não é um grande problema! A classe respeitará suas restrições e nenhuma instância inválida será criada! Ele lançará exceções para o chamador!". Sim, é verdade, mas essas mesmas exceções serão lançadas apenas em tempo de execução. E isso não é bom para ninguém!

Erros em tempo de execução explodem em produção, e esses, quando não tratados, afetam a imagem e percepção do cliente final da solução. Isso exigirá uma maneira inteligente de lidar com esses cenários, forçando os desenvolvedores a espalhar a lógica de tratamento de erros em cada ponto que irá utilizar esse código. Espalhar código e forçar esse cenário não é uma boa prática!

Em resumo, erros de compilação (compilation errors) ou de tempo de execução (runtime errors) ainda demonstram que existem problemas na solução, mas erros de compilação ajudam os desenvolvedores a descobrir problemas em tempo de compilação, o que é melhor! Vamos tentar usar o padrão Builder para impor as restrições da classe Notification em tempo de compilação.

Restringindo a ordem das chamadas de métodos no padrão Builder

O padrão Builder permite que os desenvolvedores construam objetos complexos passo a passo. O padrão Builder pode ser usado para impor as restrições da classe em tempo de compilação.

Nossa implementação do Builder não restringe a ordem das chamadas de métodos. O desenvolvedor pode chamar os métodos em qualquer ordem, o que pode levar a objetos inválidos. Isso acontece porque o NotificationBuilder expõe todos os atributos para serem definidos pelo desenvolvedor de maneira livre. Com isso, não conseguimos exigir que os métodos obrigatórios sejam chamados e assim garantir que os atributos obrigatórios tenham sido definidos. Para restringir essa ordem das chamadas de métodos, podemos estar utilizando uma variação do padrão Builder, o padrão Step Builder.

Primeiro, vamos quebrar o processo realizado pelo NotificationBuilder em alguns passos. Cada passo será responsável por definir um grupo específico de atributos. Aqui está nosso plano:

Vamos garantir que title, message e recipient sejam definidos nessa ordem específica; Às vezes é importante seguir uma ordem predefinida durante a instanciação de um objeto. Na verdade, esse não é o nosso caso, no entanto, para fins de aprendizado, vamos fazer dessa forma. Uma vez que esses atributos obrigatórios são definidos, vamos permitir que o desenvolvedor possa construir o objeto Notification com os valores padrão para os atributos opcionais, ou...
Vamos permitir que os desenvolvedores definam highPriority, type e attachment em qualquer ordem. Como esses atributos são opcionais, devemos permitir que os desenvolvedores possam construir o objeto Notification a qualquer momento a partir deste ponto;

Vamos ver como ficará:

import static java.util.Objects.requireNonNull;
import static java.util.Optional.ofNullable;

public record Notification(
        String title,
        String message,
        String recipient,
        boolean highPriority,
        Type type,
        String attachment) {

    public static enum Type {
        GENERAL, INFO, WARNING, ERROR;
    }

    public Notification(String title, String message, String recipient) {
        this(title, message, recipient, false, null, null);
    }

    public Notification {
        requireNonNull(title, "title is required");
        requireNonNull(message, "message is required");
        requireNonNull(recipient, "recipient is required");
        type = ofNullable(type).orElse(Type.GENERAL);
    }

    public static NotificationBuilder builder() {
        return new NotificationBuilder();
    }

    public static final class NotificationBuilder {

        public NotificationBuilderWithTitle title(String title) {
            return new NotificationBuilderWithTitle(title);
        }

    }

    public record NotificationBuilderWithTitle(String title) {

        public NotificationBuilderWithTitleMessage message(String message) {
            return new NotificationBuilderWithTitleMessage(this.title, message);
        }
    }

    public record NotificationBuilderWithTitleMessage(String title, String message) {

        public NotificationBuilderWithTitleMessageRecipient recipient(String recipient) {
            return new NotificationBuilderWithTitleMessageRecipient(this.title, this.message, recipient);
        }
    }

    public record NotificationBuilderWithTitleMessageRecipient(String title,
                                                               String message,
                                                               String recipient) {

        public Notification build() {
            return new Notification(title, message, recipient);
        }
    }
}

Agora, desenvolvedores devem seguir a ordem das chamadas de métodos para criar um objeto Notification. A classe NotificationBuilderWithTitle é responsável por definir o atributo title. A classe NotificationBuilderWithTitleMessage é responsável por definir o atributo message. A classe NotificationBuilderWithTitleMessageRecipient é responsável por definir o atributo recipient. A classe NotificationBuilderWithTitleMessageRecipient tem um método build() para criar um objeto Notification. Vamos destacar alguns pontos:

Todos os objetos criados pelo processo de construção são seguros para threads, o que significa que os desenvolvedores podem criar objetos Notification em um ambiente multithreaded sem problemas;
Os métodos oferecidos pelos objetos builder são nomeados, o que significa que os desenvolvedores podem saber qual método deve ser chamado em seguida para criar um objeto Notification;
A ordem das chamadas de métodos é imposta pelo padrão Builder, o que significa que os desenvolvedores devem seguir a ordem das chamadas de métodos para criar um objeto Notification e o compilador irá impor essa restrição;
Esse builder prove uma API fluente, o que significa que os desenvolvedores podem criar objetos Notification de uma maneira legível e manutenível.

Que massa! Vamos continuar a implementação para suportar a definição dos atributos opcionais.

import static java.util.Objects.requireNonNull;
import static java.util.Optional.ofNullable;

public record Notification(
        String title,
        String message,
        String recipient,
        boolean highPriority,
        Type type,
        String attachment) {

    public static enum Type {
        GENERAL, INFO, WARNING, ERROR;
    }

    public Notification(String title, String message, String recipient) {
        this(title, message, recipient, false, null, null);
    }

    public Notification {
        requireNonNull(title, "title is required");
        requireNonNull(message, "message is required");
        requireNonNull(recipient, "recipient is required");
        type = ofNullable(type).orElse(Type.GENERAL);
    }

    public static NotificationBuilder builder() {
        return new NotificationBuilder();
    }

    public static final class NotificationBuilder {

        public NotificationBuilderWithTitle title(String title) {
            return new NotificationBuilderWithTitle(title);
        }

    }

    public record NotificationBuilderWithTitle(String title) {

        public NotificationBuilderWithTitleMessage message(String message) {
            return new NotificationBuilderWithTitleMessage(this.title, message);
        }
    }

    public record NotificationBuilderWithTitleMessage(String title, String message) {

        public NotificationBuilderWithTitleMessageRecipient recipient(String recipient) {
            return new NotificationBuilderWithTitleMessageRecipient(this.title, this.message, recipient);
        }
    }

    public record NotificationBuilderWithTitleMessageRecipient(String title,
                                                               String message,
                                                               String recipient) {

        public Notification build() {
            return new Notification(title, message, recipient);
        }

        public NotificationBuilderWithTitleMessageRecipientAndMore addMore() {
            return new NotificationBuilderWithTitleMessageRecipientAndMore(
                    this.title,
                    this.message,
                    this.recipient
            );
        }
    }

    public record NotificationBuilderWithTitleMessageRecipientAndMore(String title,
                                                                      String message,
                                                                      String recipient,
                                                                      Type type,
                                                                      boolean highPriority,
                                                                      String attachment) {

        public NotificationBuilderWithTitleMessageRecipientAndMore(String title, String message, String recipient) {
            this(title, message, recipient, null, false, null);
        }

        public NotificationBuilderWithTitleMessageRecipientAndMore highPriority(boolean highPriority) {
            return new NotificationBuilderWithTitleMessageRecipientAndMore(
                    this.title,
                    this.message,
                    this.recipient,
                    this.type,
                    highPriority,
                    this.attachment
            );
        }

        public NotificationBuilderWithTitleMessageRecipientAndMore attachment(String attachment) {
            return new NotificationBuilderWithTitleMessageRecipientAndMore(
                    this.title,
                    this.message,
                    this.recipient,
                    this.type,
                    this.highPriority,
                    attachment
            );
        }

        public NotificationBuilderWithTitleMessageRecipientAndMore type(Type type) {
            return new NotificationBuilderWithTitleMessageRecipientAndMore(
                    this.title,
                    this.message,
                    this.recipient,
                    type,
                    this.highPriority,
                    this.attachment
            );
        }

        public Notification build() {
            return new Notification(
                    this.title,
                    this.message,
                    this.recipient,
                    this.highPriority,
                    this.type,
                    this.attachment
            );
        }
    }

}

Agora, após definir os atributos obrigatórios, os desenvolvedores podem criar objetos Notification definindo os atributos opcionais em qualquer ordem. A classe NotificationBuilderWithTitleMessageRecipientAndMore é responsável por definir os atributos opcionais e criar o objeto Notification. Nesse ponto, os desenvolvedores podem definir os atributos opcionais ou chamar o método build() para criar um objeto Notification arbitrariamente. Vamos destacar alguns pontos:

O builder permite que os desenvolvedores definam os atributos opcionais em qualquer ordem, o que significa que os desenvolvedores podem criar objetos Notification com os atributos opcionais em qualquer ordem;
O builder permite que os desenvolvedores criem objetos Notification arbitrariamente, o que significa que os desenvolvedores podem definir os atributos opcionais ou criar o objeto Notification em qualquer ponto do processo de construção;

Vamos atualizar o NotificationProgram que cria um objeto Notification usando o builder que implementamos:

import notification.Notification;

public class NotificationProgram {

    public static void main(String[] args) {
        var generalNotification = Notification.builder()
                .title("Another title")
                .message("Another message")
                .recipient("johndoe@system.com")
                .build();

        // do something with generalNotification

        var highPriorityWarningNotification = Notification.builder()
                .title("Warning title")
                .message("Attention people!")
                .recipient("johndoe@sytem.com")
                .addMore()
                .highPriority(true)
                .type(Notification.Type.WARNING)
                .build();

        // do something with highPriorityWarningNotification

        var highPriorityErrorNotificationWithAttachment = Notification.builder()
                .title("Warning title")
                .message("Attention people!")
                .recipient("johndoe@sytem.com")
                .addMore()
                .type(Notification.Type.ERROR)
                .attachment("error.log")
                .highPriority(true)
                .build();

        // do something with highPriorityErrorNotificationWithAttachment
    }

}

Essa implementação do builder vai além do tradicional padrão Builder.

Como podemos ver no código anterior, os desenvolvedores podem criar objetos Notification com os atributos opcionais em qualquer ordem e, ao mesmo tempo, ele impõe as restrições da classe Notification em tempo de compilação forçando a definição dos atributos obrigatórios, tornando a criação do objeto mais legível e manutenível.

Como o tio Ben Parker costumava dizer - "Com grandes poderes vêm grandes responsabilidades" - implementar o padrão Builder dessa forma tornará o código complexo, tornando-o mais difícil de entender e alterar, provavelmente. É um trade-off que você deve considerar ao usar o padrão Builder.

Uma vez que você tenha que lidar com muitos atributos (sendo eles obrigatórios ou não) para criar objetos, o padrão Builder e suas variações podem ser uma boa escolha. Como o builder está recebendo ajuda do compilador, refatorar o código será mais fácil e seguro.

Conclusão

Neste conteúdo, discutimos algumas abordagens para criar objetos com muitos atributos obrigatórios e opcionais. Começamos com a abordagem tradicional, usando construtores e setters para criar objetos. Vimos que essa abordagem pode levar a objetos inválidos, problemas de segurança de threads e código verboso. Em seguida, exploramos algumas abordagens como:

Telescope constructors;
Static Method Factory;
Builder pattern;
Fluent API design style;
Step Builder pattern.

Toda a abordagem têm seus prós e contras. A abordagem dos construtores telescópicos pode resolver alguns cenários, mas pode ser propensa a erros e verbosa ao lidar com muitos atributos. O Static Method Factory pode oferecer uma boa alternativa para construir objetos quando poucos atributos são necessários. O padrão Builder permite que os desenvolvedores construam objetos complexos passo a passo usando o estilo de design Fluent API, fornecendo uma interface fluente, tornando a criação do objeto mais legível e manutenível e, o padrão Step Builder pode ser usado para impor as restrições da classe em tempo de compilação. No final, pudemos ver como essas abordagens podem ajudar os desenvolvedores a facilitar suas vidas ao criar objetos com muitos atributos.

Lições aprendidas

Tornar a vida dos desenvolvedores mais fácil é tão importante quanto tornar a vida dos clientes finais mais fácil;
A abordagem Telescoping Constructors pode resolver alguns cenários, mas pode ser propensa a erros e verbosa ao lidar com muitos atributos;
Static Method Factory pode oferecer uma boa alternativa para construir objetos quando poucos atributos são necessários;
O padrão Builder permite que os desenvolvedores construam objetos complexos passo a passo;
O estilo de design Fluent API pode ajudar os desenvolvedores a criar código especializado focado em encadeamento de métodos, melhorando a experiência do desenvolvedor. Normalmente é usado para expressar linguagens específicas de domínio. Em nosso contexto, foi usado para criar um builder mais fácil de usar, permitindo que os desenvolvedores criem objetos de uma forma legível e manutenível;
A variação do padrão Builder chamado Step Builder pattern permite que os desenvolvedores criem objetos complexos definindo os atributos seguindo uma ordem predefinida;

Pensamentos finais

Eu espero que você tenha gostado deste conteúdo! Se você tiver alguma dúvida ou feedback, por favor, sinta-se à vontade para entrar em contato. Eu adoraria ouvir de você!

Muitos projetos open-source em Java trazem essas abordagens para criar objetos com muitos atributos opcionais. O Lombok, por exemplo, fornece a anotação @Builder para gerar o padrão Builder para você, mas é importante entender como ele funciona para poder usá-lo de maneira eficiente.

Os design patterns e estilos de design de código podem (pra não dizer que devem) ser misturados e combinados conforme necessário para resolver o problema que estão resolvendo. Não existe bala de prata no desenvolvimento de software. Cada abordagem tem seus prós e contras e ninguém melhor do que você para saber qual é a melhor para o seu cenário.

Para ver um bom exemplo que usa algumas dessas técnicas na prática, dê uma olhada no projeto Eclipse JNoSQL, na classe org.eclipse.jnosql.mapping.semistructured.AbstractSemiStructuredTemplate no método QueryMapper.MapperFrom select(Class<T> type). Ele usa um estilo de design Fluent API para ajudar os usuários a realizar consultas para recuperar dados de implementações de banco de dados NoSQL semi-estruturados.

Se você quer aprender mais sobre o padrão Builder, eu recomendo os seguintes recursos:

Além disso, eu gostaria de recomendar que você coloque essas abordagens em prática no seu dia a dia. Isso ajudará você a entender quando usar cada uma e como aplicá-las de forma eficaz.

Gostou deste conteúdo? Se sim, por favor, compartilhe com seus amigos e colegas. Além disso, não se esqueça de me seguir nas redes sociais para ficar atualizado com os últimos conteúdos e atualizações.

Até o próximo conteúdo!

[PT-BR] Por que não é uma boa prática usar 'Object' como um tipo genérico em Java?

Maximillian Arruda — Tue, 17 Dec 2024 23:18:47 +0000

Caso queira conferir esse conteúdo em inglês, fique a vontade clicando aqui: The Challenges of Using 'Object' as a Catch-All Type in Java.

Durante uma sessão de mentoria, conversando sobre Generics em Java com o desenvolvedor mentorado, percebemos que alguns conceitos precisam ser dominados para trazer mais valor quanto as motivações e o real valor na utilização de Generics no Java. Daí surgiu a pergunta: "Por que não é uma boa prática usar Object como um tipo genérico em Java?"

Achei esta pergunta é muito interessante e é por isso que estou abordando esse assunto neste conteúdo.

Muito bem, vamos lá!

Como um desenvolvedor Java, você deve saber que java.lang.Object é a raiz da hierarquia de classes na linguagem. Toda classe herda de Object, incluindo arrays. Isso significa que todos os objetos são, por padrão, instâncias de Object.

Bem, se toda classe herda de Object, por que não é uma boa prática usar Object como um tipo genérico em Java? Vamos conferir!

Usando Object para Armazenar Qualquer Tipo de Objeto

Quando declaramos variáveis, você pode tipar a variável como Object como para armazenar qualquer objeto quando o seu tipo específico é desconhecido.

    Object infoA = "Maximillian"; // Isso funciona porque String é um Object!
    Object infoB = 45; // Isso funciona, porque Integer é um Object!

Tais declarações podem compor um programa Java válido, como mostrado abaixo:

class ObjectAsCatchAllTypeProgram {
    public static void main(String[] args) {
        Object infoA = "Maximillian"; // Isso funciona, pois String é um Object!
        System.out.println(infoA);
    }
}

A saida deste programa será:

$ java ObjectAsCatchAllTypeProgram.java
Maximillian

Isso acontece porque String é uma subclasse de Object, logo o compilador não irá encontrar nenhum problema sintático. Além disso, você pode alterar o valor de infoA para um objeto de qualquer outro tipo, e o programa ainda continuará funcionando:

class ObjectAsCatchAllTypeProgram {
    public static void main(String[] args) {
        Object infoA = 3.14; // Isso funciona porque Double é um Object!
        System.out.println(infoA);
    }
}

A saída será:

$ java ObjectAsCatchAllTypeProgram.java
3.14

Como podemos ver, o programa funciona independentemente do tipo de objeto atribuído à variável infoA.

Mas quais são os benefícios de usar Object como um tipo? Alguns desenvolvedores podem dizer: "Isso torna o código mais flexível e reutilizável." Mas será que isso é verdade?

Limitações ao Usar Object: Falta de Segurança de Tipos

Sim, não existe uma "bala de prata" na área de desenvolvimento de software. Cada decisão tem seus prós e contras. Vamos explorar as limitações de usar Object como um tipo genérico.

Independente do tipo de objeto, você só pode interagir com ele através de sua interface. Neste contexto, a palavra "interface" significa os métodos que estão expostos através da classe de seu tipo.

Uma classe é a receita ou um modelo para os objetos derivados dessa tal classe. Quando você define uma classe, você está especificando seu tipo, a estrutura e o comportamento dos objetos criados a partir dela. A classe define os atributos (o estado, ou seja, seus dados) e métodos (comportamento) que os objetos terão. Esses métodos permitem que os objetos interajam entre si.

A classe Object inclui alguns métodos comuns, como toString(), equals() e hashCode(). Esses métodos são úteis em muitos casos, mas não são suficientes quando você deseja interagir com métodos específicos de uma classe particular.

Vamos supor que estamos armazenando um objeto String em uma variável declarada como Object, e queremos obter o comprimento do valor( a string) que foi atribuído. Veja o que acontece:

class ObjectAsCatchAllTypeProgram {
    public static void main(String[] args) {
        Object infoA = "Maximillian"; // Isso funciona porque String é um Object, mas...
        System.out.println(infoA.length());
    }
}

Tentando executar o código acima, teremos o seguinte resultado:

$ java ObjectAsCatchAllTypeProgram.java
ObjectAsCatchAllTypeProgram.java:5: error: cannot find symbol
        System.out.println(infoA.length());
                                ^
  symbol:   method length()
  location: variable infoA of type Object
1 error
error: compilation failed

Quando você declara uma variável como Object, você perde a segurança de tipos, para os íntimos, Type safety. Type safety é uma característica do Java que impede que você atribua um objeto de um tipo a uma variável de outro tipo. Essa característica ajuda a detectar erros em tempo de compilação, tornando seu código mais confiável. No exemplo acima, o compilador não sabe que infoA é um instancia de um objeto do tipo String, então ele não permitirá que você chame o método length() nele, gerando assim um erro de compilação (compilation error).

Limitações ao Usar Object: A necessidade de conversão de tipos explícita

Para interagir com um objeto como seu tipo específico, você precisa convertê-lo para esse tipo. A conversão, ou em "javanês", Casting, é o processo de converter um objeto de um tipo para outro. Em Java, você pode converter um objeto (fazer um casting) para um tipo de subclasse ou superclasse. Vamos converter infoA para String antes de chamar o método length() para corrigir o erro de compilação mostrado anteriormente:

class ObjectAsCatchAllTypeProgram {
    public static void main(String[] args) {
        Object infoA = "Maximillian"; // Isso funciona porque String é um Object, mas...
        String name = (String) infoA;
        System.out.println(name.length());
    }
}

Com isso, a saída será:

$ java ObjectAsCatchAllTypeProgram.java
11

Neste ponto, você pode pensar: "Não é um grande problema; eu posso apenas fazer um casting do objeto para seu tipo antes de interagir com ele." Será? Mesmo para um codebase de médio pra grande?

Limitações ao Usar Object: Propenso a erros em tempo de execução

Vamos explorar um cenário diferente:

class ObjectAsCatchAllTypeProgram {
    public static void main(String[] args) {
        Object infoA = 11; // Isso funciona porque Integer é um Object, mas
        String name = (String) infoA;  // Isso não é um String, é um Integer!!!
        System.out.println(name.length());
    }
}

Executando este código, teremos:

$ java ObjectAsCatchAllTypeProgram.java
Exception in thread "main" java.lang.ClassCastException: class java.lang.Integer cannot be cast to class java.lang.String (java.lang.Integer and java.lang.String are in module java.base of loader 'bootstrap')
        at ObjectAsCatchAllTypeProgram.main(ObjectAsCatchAllTypeProgram.java:4)

Um ClassCastException foi lançado porque estamos tentando fazer um cast de um objeto Integer para um objeto String. Integer não é uma subclasse de String, então o cast falha. Este tipo de erro é o que chamados de erro em tempo de execução, ou runtime error.

Vamos explorar outro caso:

class ObjectAsCatchAllTypeProgram {
    public static void main(String[] args) {
        Object infoA = null; // Oops, estamos atribuindo null, e agora...?!?!?
        String name = (String) infoA;
        System.out.println(name.length());
    }
}

E como resultado, teremos:

$ java ObjectAsCatchAllTypeProgram.java
Exception in thread "main" java.lang.NullPointerException: Cannot invoke "String.length()" because "<local2>" is null
        at ObjectAsCatchAllTypeProgram.main(ObjectAsCatchAllTypeProgram.java:5)

Um NullPointerException ocorre porque estamos tentando chamar um método a partir de uma variável onde seu valor é uma referência nula.

Você pode pensar: "Eu posso facilmente corrigir isso usando um bloco try-catch ou o operador instanceof." Vamos tentar lidar com isso usando ambos os métodos:

Usando um bloco try-catch:

class ObjectAsCatchAllTypeProgram {
    public static void main(String[] args) {
        Object infoA = null; // Oops, estamos atribuindo null, e agora...?!?!?
        try {
            String name = (String) infoA;
            System.out.println(name.length());
        } catch (NullPointerException ex) {
            System.out.println("infoA não pode ser convertido pois seu valor é null");
        } catch (ClassCastException ex) {
            System.out.println("infoA não pode ser convertido para String");
        }
    }
}

Output:

$ java ObjectAsCatchAllTypeProgram.java
infoA não pode ser convertido pois seu valor é null

Usando o operador instanceof:

class ObjectAsCatchAllTypeProgram {
    public static void main(String[] args) {
        Object infoA = null; // Oops, estamos atribuindo null, e agora...?!?!?
        if (infoA instanceof String) {
            String name = (String) infoA;
            System.out.println(name.length());
        } else {
            System.out.println("infoA não pode ser convertido para String");
        }
    }
}

Output:

$ java ObjectAsCatchAllTypeProgram.java
infoA não pode ser convertido para String

Estratégias para tratar esses cenários podem ajudar sim, mas elas não são tão práticas caso seja preciso utilizá-las toda vez que você precisar interagir com um objeto do tipo Object.

Usando o operador instanceof é uma boa prática quando você precisa verificar o tipo de um objeto antes de fazer um cast. No entanto, isso pode tornar seu código mais complexo e difícil de ler, pois é preciso além de passar pelo operador instanceof precisaremos fazer o casting. Já o bloco try-catch é útil para lidar com exceções, mas também pode tornar seu código mais verboso e difícil de manter.

Se você está usando Java 14 ou superior, podemos usar o recurso Pattern Matching for Instanceof (JEP305). Esse aprimoramento de linguagem integrado nos ajuda a escrever um código melhor e mais legível.

class ObjectAsCatchAllTypeProgram {
    public static void main(String[] args) {
        Object infoA = null;
        if (infoA instanceof String name) { // muito mais elegante, não é? :-)
            System.out.println(name.length());
        } else {
            System.out.println("infoA não pode ser convertido para String");
        }
    }
}

Aqui está a saída:

$ java ObjectAsCatchAllTypeProgram.java
infoA não pode ser convertido para String

Conclusão

Nós aprendemos que declarar variáveis como java.lang.Object é geralmente considerado uma má prática, a menos que haja uma razão específica e convincente. Usar Object sacrifica a segurança de tipos, a legibilidade e a manutenibilidade. Na maioria dos casos, é melhor usar um tipo mais específico para aproveitar ao máximo o sistema de tipagem forte do Java.

Durante nossa exploração, descobrimos que erros de compilação (compilation errors) e erros em tempo de execução (runtime errors) podem ocorrer ao usar Object como um tipo genérico. Vamos recapitular as diferenças entre esses dois tipos de erros:

Erros de compilação (compilation errors) ocorrem durante a fase de compilação quando o código não pode ser convertido em bytecode. Esses erros previnem que o programa seja compilado.
Errors de tempo de execução (runtime errors) ocorrem após a compilação bem-sucedida e podem fazer com que o programa se comporte de forma imprevisível ou falhe. Erros de tempo de execução são tipicamente mais problemáticos porque podem afetar ambientes de produção.

Ambos os tipos de erros indicam problemas, mas os erros em tempo de execução são geralmente mais graves porque podem afetar os usuários e causar comportamentos inesperados, enquanto os erros de compilação são mais fáceis de resolver durante o processo de desenvolvimento do software.

Uma boa prática é implementar uma boa estratégia de tratamento de erros (Error Handler) para lidar com erros em tempo de execução, capturando as exceções e registrando-as corretamente para ajudá-lo a depurar e corrigir os problemas quando eles surgirem (e vão surgir!).

Lições Aprendidas

Através deste conteúdo, exploramos os desafios de usar Object como um tipo genérico. Aprendemos que usar Object pode levar a:

Lack of type safety (Falta de segurança de tipos): Se o compilador não sabe o tipo específico de um objeto declarado como Object, logo ele não pode detectar erros relacionados ao tipo em tempo de compilação. Isso pode levar a erros em tempo de execução ao interagir com os objetos do tipo Object.
A necessidade de conversão de tipos explícita : Para interagir com um objeto como seu tipo específico, você precisa convertê-lo para esse tipo. Fazer isso em demasia espalhando essas instruções podem tornar seu código mais complexo e difícil de ler.
Propenso a erros em tempo de execução: Usar Object como um tipo genérico pode levar a erros em tempo de execução, como ClassCastException e NullPointerException. Esses erros podem ser difíceis de rastrear, depurar e corrigir, especialmente em codebases grandes.
Necessidade adicional de tratamento de erros: Para prevenir erros em tempo de execução, você pode precisar usar blocos try-catch ou o operador instanceof. Embora essas estratégias possam ajudar, elas podem tornar seu código mais verboso e difícil de manter. Recomendo usar uma boa estratégia de tratamento de erros para lidar com erros em tempo de execução, capturando as exceções e registrando-as corretamente para ajudá-lo a depurar e corrigir os problemas.

Considerações finais

Nem sempre usar Object como um tipo genérico é a melhor solução. Em alguns casos, usar Object pode ser mais apropriado. Por exemplo, quando você não tem controle sobre o tipo de objeto que será manipulado. No entanto, é importante entender as limitações e desafios associados ao uso de Object e saber quando é apropriado usá-lo.

Quando questões sobre o que é certo ou errado na área de desenvolvimento de software surgem em qualquer discussão, costumamos ver desenvolvedores respondendo assim: "Ah, isso depende do contexto com o qual você está trabalhando." E sim, eles estão certos!

Mas, uma vez que você conhece o contexto, "depende" não é mais uma resposta tão válida assim. No fim, o contexto do problema deve ser utilizado para nos guiar a tomar uma melhor decisão!

Então, favoreça tipos mais específicos sempre que possível para aproveitar ao máximo o poder do sistema de tipagem do Java. Isso ajudará você a escrever um código mais legível, manutenível e confiável.

O que você acha de usar Object como um tipo genérico em Java? Você tem alguma experiência ou melhores práticas para compartilhar? Sinta-se à vontade para deixar seus pensamentos nos comentários abaixo!

Próximos passos

Parabéns por chegar ao final deste conteúdo! Espero que você tenha achado informativo e útil.

Os conceitos aprendidos neste conteúdo são essenciais para entender a motivação por trás do uso de Generics no Java. Generics é um recurso poderoso que permite escrever um código mais flexível e seguro em relação ao tipo, fornecendo verificação de tipo em tempo de compilação.

Gosto deste conteúdo? Se sim, por favor, compartilhe com seus amigos e colegas. Estou aceitando sugestões de assuntos para os próximos e futuros conteúdos, então, sinta-se à vontade para sugerir nos comentários, ok?

Também não se esqueça de me seguir nas redes sociais para ficar atualizado com os últimos conteúdos e atualizações.

Até a próxima!

The Challenges of Using 'Object' as a Catch-All Type in Java

Maximillian Arruda — Sun, 15 Dec 2024 23:27:14 +0000

If you prefer to read this content in Brazilian Portuguese, follow this link [PT-BR] Por que não é uma boa prática usar 'Object' como um tipo genérico em Java?.

During a mentoring session with a mentee developer where we got started to talk about Java Generics, we realized that some concepts need to be mastered before than talk about Java Generics. Suddenly, a question came up: "Why it is not a good practice to use Object as a catch-all type in Java?"

IMHO this question is very interesting and that's the reason why I'm covering this subject in this content.

Okay, let's get started!

As a Java developer, you should know that java.lang.Object is the root of the class hierarchy. Every class inherits from Object, including arrays. This means that all objects are, by default, instances of Object.

Well, if every class inherits from Object then why is it not a good practice to use Object as a catch-all type in Java? Let's check it out!

Using Object to Hold Any Type of Object

When declaring variables, you can use Object as the type to hold any object when the specific type is unknown.

    Object infoA = "Maximillian"; // Works fine, because String is an Object!
    Object infoB = 45; // Works fine, because Integer is an Object!

Such declarations can be part of a valid Java program, as shown below:

class ObjectAsCatchAllTypeProgram {
    public static void main(String[] args) {
        Object infoA = "Maximillian"; // Works fine, because String is an Object!
        System.out.println(infoA);
    }
}

The output of this program will be:

$ java ObjectAsCatchAllTypeProgram.java
Maximillian

This happens because String is a subclass of Object, and the compiler does not complain about it. Additionally, you can change the value of infoA to an object of any type, and the program will still work fine:

class ObjectAsCatchAllTypeProgram {
    public static void main(String[] args) {
        Object infoA = 3.14; // Works fine, because Double is an Object!
        System.out.println(infoA);
    }
}

The output will be:

$ java ObjectAsCatchAllTypeProgram.java
3.14

As we can see, the program works regardless of the type of object assigned to the infoA variable.

But what are the benefits of using Object as a type? Some developers might say, "It makes the code more flexible and reusable." But is it true?

Limitations of Using Object: Lack of type safety

Yeah, there is no "silver bullet" in the software development area. Every decision has its pros and cons. Let's explore the limitations of using Object as a catch-all type.

Regardless of the type of object, you can only interact with it through its interface. In this context the "interface" word means the exposed methods declared on its class.

A class is a blueprint for an object. When you define a class, you're specifying its type, the structure and behavior of the objects created from it. The class defines the attributes (data) and methods (behavior) that the objects will have. These methods allow objects to interact with one another.

The Object class includes some common methods, such as toString(), equals(), and hashCode(). These methods are useful in many cases, but they are not sufficient when you want to interact with specific methods of a particular class.

Let’s suppose we are holding a String object in a variable declared as Object, and we want to get the length of the assigned value. Here's what happens:

class ObjectAsCatchAllTypeProgram {
    public static void main(String[] args) {
        Object infoA = "Maximillian"; // Works fine, because String is an Object, but...
        System.out.println(infoA.length());
    }
}

Trying to run the code above results in:

$ java ObjectAsCatchAllTypeProgram.java
ObjectAsCatchAllTypeProgram.java:5: error: cannot find symbol
        System.out.println(infoA.length());
                                ^
  symbol:   method length()
  location: variable infoA of type Object
1 error
error: compilation failed

When you declare a variable as Object, you lose type safety. Type safety is a feature of Java that prevents you from assigning an object of one type to a variable of another type. This feature helps catch errors at compile time, making your code more reliable. In the example above, the compiler doesn't know that infoA is a String object, so it doesn't allow you to call the length() method on it by raising a compilation error.

Limitations of Using Object: The need for explicit casting

To interact with an object as its specific type, you need to cast it to that type. Casting is the process of converting an object from one type to another. In Java, you can cast an object to a subclass or superclass type. Let’s cast infoA to String before calling the length() method to fix the compilation failed showed before:

class ObjectAsCatchAllTypeProgram {
    public static void main(String[] args) {
        Object infoA = "Maximillian"; // Works fine, because String is an Object, but...
        String name = (String) infoA;
        System.out.println(name.length());
    }
}

The output will now be:

$ java ObjectAsCatchAllTypeProgram.java
11

At this point, you might think, "It's not a big deal; I can just cast the object to its type before interacting with it." But can we be sure?

Limitations of Using Object: Susceptibility to runtime errors

Let’s take a look at a different scenario:

class ObjectAsCatchAllTypeProgram {
    public static void main(String[] args) {
        Object infoA = 11; // Works fine, because Integer is an Object, but...
        String name = (String) infoA;  // It's not a String, it's an Integer!!!
        System.out.println(name.length());
    }
}

Running this results in:

$ java ObjectAsCatchAllTypeProgram.java
Exception in thread "main" java.lang.ClassCastException: class java.lang.Integer cannot be cast to class java.lang.String (java.lang.Integer and java.lang.String are in module java.base of loader 'bootstrap')
        at ObjectAsCatchAllTypeProgram.main(ObjectAsCatchAllTypeProgram.java:4)

A ClassCastException is thrown because we're trying to cast an Integer object to a String object. Integer is not a subclass of String, so the cast fails. This is a runtime error.

Let’s explore another case:

class ObjectAsCatchAllTypeProgram {
    public static void main(String[] args) {
        Object infoA = null; // Oops, a null value?!?!
        String name = (String) infoA;
        System.out.println(name.length());
    }
}

This will result in:

$ java ObjectAsCatchAllTypeProgram.java
Exception in thread "main" java.lang.NullPointerException: Cannot invoke "String.length()" because "<local2>" is null
        at ObjectAsCatchAllTypeProgram.main(ObjectAsCatchAllTypeProgram.java:5)

A NullPointerException occurs because we're trying to call a method on a null reference.

You might think, "I can easily fix this using a try-catch block or the instanceof operator." Let’s try to handle it with both approaches:

Using a try-catch block:

class ObjectAsCatchAllTypeProgram {
    public static void main(String[] args) {
        Object infoA = null; // Oops, a null value?!?!
        try {
            String name = (String) infoA;
            System.out.println(name.length());
        } catch (NullPointerException ex) {
            System.out.println("infoA cannot be cast because it's null");
        } catch (ClassCastException ex) {
            System.out.println("infoA cannot be cast to String");
        }
    }
}

Output:

$ java ObjectAsCatchAllTypeProgram.java
infoA cannot be cast because it's null

Using the instanceof operator:

class ObjectAsCatchAllTypeProgram {
    public static void main(String[] args) {
        Object infoA = null; // Oops, a null value?!?!
        if (infoA instanceof String) {
            String name = (String) infoA;
            System.out.println(name.length());
        } else {
            System.out.println("infoA cannot be cast to String");
        }
    }
}

Output:

$ java ObjectAsCatchAllTypeProgram.java
infoA cannot be cast to String

While these strategies can help, they are not practical to use every time you need to interact with an object.

Using instanceof is a good practice when you need to check the type of an object before casting it. However, it can make your code more complex and harder to read. The try-catch block is useful for handling exceptions, but it can also make your code more verbose and harder to maintain.

If you're using Java 14 or above, we can use the Pattern Matching for Instanceof (JEP305) feature. Such built-in language enhancement helps us to write better and more readable code.

class ObjectAsCatchAllTypeProgram {
    public static void main(String[] args) {
        Object infoA = null; 
        if (infoA instanceof String name) { // more concise, isn't it? :-)
            System.out.println(name.length());
        } else {
            System.out.println("infoA cannot be cast to String");
        }
    }
}

Here's the output:

$ java ObjectAsCatchAllTypeProgram.java
infoA cannot be cast to String

Conclusion

We learned that being declaring variables as java.lang.Object is generally considered bad practice unless there is a specific, compelling reason. Using Object sacrifices type safety, readability, and maintainability. In most cases, it’s better to use a more specific type to take full advantage of Java's strong typing system.

During our exploration, we discovered that compilation errors and runtime errors can occur when using Object as a catch-all type. Let’s recap the differences between these two types of errors:

Compilation errors happen during the compilation phase when the code cannot be converted into bytecode. These errors prevent the program from running.
Runtime errors occur after successful compilation and can cause the program to behave unpredictably or crash. Runtime errors are typically more problematic because they can affect production environments.

While both types of errors indicate issues, runtime errors are usually more severe because they can affect users and cause unexpected behavior, while compilation errors are easier to resolve during development.

A good practice is to implement a good error handling strategy to deal with runtime errors, capturing the exceptions and logging them properly to help you debug and fix the issues.

Key Takeaways

Through this content, we explored the challenges of using Object as a catch-all type. We learned that using Object can lead to:

Lack of type safety: The compiler doesn't know the specific type of an object declared as Object, so it can't catch type-related errors at compile time. This can lead to runtime errors when interacting with the object.
The need for explicit casting: To interact with an object as its specific type, you need to cast it to that type. This can make your code more complex and harder to read.
Susceptibility to runtime errors: Using Object as a catch-all type can lead to runtime errors, such as ClassCastException and NullPointerException. These errors can be difficult to track, debug, and fix, especially in large codebases.
The need for additional error handling: To prevent runtime errors, you might need to use try-catch blocks or the instanceof operator. While these strategies can help, they can make your code more verbose and harder to maintain. I recommend using a good error handler strategy to deal with runtime errors, capturing the exceptions and logging them properly to help you debug and fix the issues.

Final Thoughts

Not always using Object as catch-all type is the best solution. In some cases, using Object can be more appropriate. For example, when you have no control over the type of object that will be manipulated. However, it is important to understand the limitations and challenges associated with using Object and know when it is appropriate to use it.

When questions about what's right or wrong in the software development area comes to any discussion, we use to see developers answering like that: "It depends on the context that you're handling with." And they are right!

But, once you know the context, "it depends" is not so valid answer. The problem context should guide us to make a good decision!

So, I recommend you favor using more specific types whenever possible to take full advantage of Java's strong typing system. This will help you write more readable, maintainable, and reliable code.

What do you think about using Object as a catch-all type in Java? Do you have any experiences or best practices to share? Feel free to leave your thoughts in the comments below!

Next steps

Congratulations on reaching the end of this content! I hope you found it informative and helpful.

The learned concepts in this content are essential for understanding the motivation behind using generics in Java. Generics are a powerful feature that allows you to write more flexible, type-safe code by providing compile-time type checking.

Did you like this content? If so, please share it with your friends and colleagues. I'm accepting subject suggestions for the next and future contents, so, feel free to suggest in the comments, okay?

Also, don't forget to follow me on social media to stay up to date with the latest content and updates.
See you in the next content!

[PT-BR] Transformando listas com Java Stream API

Maximillian Arruda — Tue, 13 Sep 2022 17:05:06 +0000

E aí pessoal! Espero que todos estejam bem!!!

Bom, após descansar do TDC Business 2022, onde tive a honra e a felicidade de realizar um sonho: ser coordenador na trilha de Carreira e Mentoria, ser expositor da empresa em que trabalho (StackSpot) e ser palestrante na trilha de arquitetura Java, falando sobre Streams API junto com Rolmer Telis de Oliveria, estou de volta explorando, estudando e aprendendo cada vez mais sobre Programação Funcional com Java.

No artigo anterior, vimos que a partir do Java 8, a interface Iterable foi melhorada com um método especial: um default method chamado forEach. Agora, caso estivermos trabalhando com objetos que implementam a interface Iterable, poderemos usufruir desse método para iterar nos itens de maneira declarativa, utilizando uma lambda expression ou method references.

Mas o que são Default Methods

A feature default method, que foi adicionado ao Java 8, permitiu uma evolução suave de toda a API do Java, permitindo métodos padrões fossem implementados em interfaces, mantendo assim toda uma retro-compatibilidade das versões anteriores do Java.

Com isso, podemos dizer que todos objetos que implementam a interface Iterable poderão usufruir do método forEach, já que esse é um default method, implementado na própria interface Iterable.

Muito mais que iterar em uma lista

Já conhecemos o método forEach, na qual podemos iterar nos itens de uma determinada lista ou coleções, mas sabemos também que só iterar não nos basta!

Sem dúvida, vamos ter que realizar operações muito mais complexas: como filtrar, transformar ou modificar os dados dessas listas.

Manipular coleções para produzir outros resultados é tão comum como iterar através dos elementos de uma coleção.

Vamos dizer que precisamos pegar uma lista de produtos e pegar só os preços desses produtos.

Abaixo segue o Record que representará nosso produto:

PS: Vamos utilizar a especificação JSR 354 Java Money¹

  record Product(String description, MonetaryAmount price) {}

E aqui está a lista de produtos:

  var currency = Monetary.getCurrency("BRL");
  var products = List.of(
      new Product("bean", Money.of(5.99,currency)),
      new Product("rice", Money.of(12.49,currency)),
      new Product("coffee", Money.of(18.99,currency)),
      new Product("bread", Money.of(6.59,currency)),
      new Product("chocolate", Money.of(6.80,currency))
  );

Uma vez que estamos utilizando uma lista imutável criada através do método List.of, nós precisamos criar uma nova lista para armazenar esses preços.

Utilizando uma abordagem imperativa, nós escreveríamos um código parecido com esse:

  List<MonetaryAmount> prices = new ArrayList<>();
  for(Product product: products){
      prices.add(product.price());
  }

Precisamos criar uma lista vazia para só então coletar todos os preços ao iterar pelos produtos da lista. Como primeiro passo para utilizar um estilo funcional, vamos usar o internal interator forEach fornecido pela interface Iterable, como fizemos no blogpost anterior.

  List<MonetaryAmount> prices = new ArrayList<>();
  products.forEach(product -> prices.add(product.price()));

Estamos utilizando um internal iterator, mas ainda há a necessidade de criar uma lista vazia e ainda assim adicionar os preços item a item. Que tal explorar um pouco uma abordagem mais funcional para solucionar esse detalhe?

Muito mais que um simples iterador!

A criação de uma lista vazia e a manipulação explicita desta instância introduz variáveis mutáveis, o que deixam o nosso código mais propenso a erros, pois estamos, além de iterar pelos produtos, temos que nos preocupar em coletar só os preços e adicioná-los na nova lista: estamos instruindo nosso programa como a coleta deve ser feita ao invés de declarar qual é a informação que queremos coletar explicitamente.

A partir do Java 8, a interface Stream² foi adicionada com o intuito de permitir a manipulação de coleções de maneira mais declarativa, mais funcional.

A interface Stream é muito mais que um simples iterador: ela fornece uma API fluente na qual nos permite, em conjunto com Lambda Expressions e Reference Methods, encadear operações que podem ou não utilizar objetos de função afim de nos permitir executar tarefas como filtrar, mapear ou transformar, contar, reduzir e por aí vai.

Graças aos default methods, objetos que implementam uma Collection detém o método stream para adquirir instâncias do tipo Stream.

Abaixo, vamos utilizar um Stream a partir da lista de produtos:

  List<MonetaryAmount> prices = products
                .stream()
                .map(product -> product.price)
                .collect(Collectors.toList());

Como podemos ver, um método chamado map fornecido pela interface Stream nos permitem mapear ou transformar cada item do Stream no valor solicitado, nesse caso, o preço de cada produto. No passo seguinte, instruímos o Stream para que, através do método collect, colete o resultado como uma nova lista, e isso está sendo declarado através de uma instância do tipo Collector fornecido através da chamada do método toList da classe fábrica Collectors.

Do ponto de vista de execução, você pode pensar que cada método, que representa uma operação, é executada de maneira eager, ou seja, no momento da chamada da operação, mas isso não é verdade para alguns metodos da interface Stream.

A interface Stream fornece as operações intermediárias e operações terminadoras.

As operações intermediárias são operações lazy, isto é, elas só são performadas quando uma operação terminal é executada.

Já as operações terminadoras são responsáveis por efetivamente desencadear toda as operações encadeadas através da interface fluente Stream.

O encadeamento dessas operações ocorre com uma ou várias operações intermediárias em conjunto com uma operação terminal, formando assim o Stream Pipeline. Vamos conhecer mais sobre a interface Stream em blogposts futuros! 😉

Em nosso exemplo, a operação map é uma operação intermediária, e ela só será disparada quando alguma operação terminal for executada, no nosso caso, a operação collect.

Agora, em nosso exemplo, não estamos lidando mais com váriaveis mutáveis, e assim deixando declarativo o que queremos. Não precisamos mais criar uma lista vazia. Todas essas preocupações estão sendo controladas e delegadas para a implementação fornecida pela API do Java.

Mas podemos também utilizar no lugar da Lambda Expression um Method Reference, diminuindo ainda mais a chance de algum possível erro na lógica de dentro da declaração da expressão. Vejamos como fica o resultado:

  List<MonetaryAmount> prices = products
                .stream()
                .map(Product::price)
                .collect(Collectors.toList());

Talvez, você deve estar se perguntando:

Quando devemos utilizar Method References?

Nós normalmente utilizamos muito mais lambda expressions do que method references quando estamos programando em Java. Mas isso não significa que method references não são importantes ou menos útil.

Se uma lambda expression simplesmente repassa os parâmetros para outro método, mesmo sendo um método de uma instância ou estático, podemos substitui-la pelo método em questão, referenciando-o, por isso o nome method reference.

Além de deixar o código conciso do que utilizando lambda expressions, ao utilizar method reference ganhamos a habilidade de utilizar métodos nomeados, e assim facilitar a compreensão do código.

Mas e quanto a performance?

Como já sabemos, a linguagem Java já tem um longo caminho e é usada em um grande número de aplicativos corporativos onde o desempenho é crítico. Mas mesmo sabendo disso, é muito razoável questionar se as novas features afetarão o desempenho.

A resposta é sim, mas principalmente para melhor! Pode parecer ingênuo essa afirmação a princípio, mas antes de discutirmos sobre melhorias de desempenho, vamos lembrar as sábias palavras de Donald Knuth:

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

Traduzindo:

Devemos esquecer as pequenas eficiências, digamos que cerca de 97% das vezes: a otimização prematura é a raiz de todo o mal.

Com isso em mente, devemos ser ousados em experimentar novos estilos onde eles podem fazer sentido. Se, ao utilizar o novo estilo e esse atender o desempenho adequado às necessidades da aplicação, então podemos adotá-lo e seguir em frente, caso contrário, devemos avaliar de forma crítica o design de código afim de encontrar os gargalos reais que o código está apresentando.

As especificações inseridas a partir do Java 8 fornecem um grande flexibilidade para facilitar as otimizações do compilador. Essas otimizações em conjunto com a instrução otimizada do bytecode InvokeDynamic podem fazer com que as chamadas utilizando Lambda Expressions sejam bem rápidas.

Vamos fazer um teste sobre performance.

Abaixo, temos um código imperativo que contam os números primos em uma coleção de números:

  long count = 0;
  for (long number : numbers) {
      if (isPrime(number)) {
          count++;
      }
  }

Utilizamos no examplo o habitual for loop para invocar um método isPrime para determinar se cada número na coleção é um número primo. Se ele for primo, nós incrementamos a variável count. Vamos medir o tempo considerando uma lista de 1.000.000 (um milhão) de números.

  PT0.163687193S

Isso levou aproximadamente 0.163 segundos, mas vamos reduzir esse código; vamos ver ver se utilizando um novo estilo que queremos adotar bate esse desempenho. Vamos refatorar o código para o estilo funcional: onde o código é declarativo, é criado favorecendo a imutabilidade, não tem efeitos colaterais, seguindo um encadeamento de funções de primeira ordem:

 numbers.stream()
         .filter(i -> isPrime(i))
         .count();

Aqui, transformamos a coleção em um Stream e então aplicamos um filtro através de uma operação intermediária, filter, declarando que queremos somente os números primos da coleção, e finalmente efetuamos o cálculo ao performar a operação terminal count. Vamos ver quanto tempo essa versão levou para executar a mesma lógica na mesma coleção de 1.000.000 (um milhão) de números:

 PT0.167082778S

A saída, como podemos ver, utilizando lambda expression, foi aproximadamente o mesmo: 0.167 segundos; Pode parecer que não ganhamos ou perdemos nada, mas na verdade, ganhamos muito sim!

É algo trivial paralelizar códigos desenvolvidos utilizando o estilo funcional, agora paralelizar um código imperativo, por outro lado, se ele já não foi arquitetado para esse fim, provavelmente não será algo tão trivial assim, não é?

Segue uma versão utilizando o estilo funcional e paralelizada de nosso código:

  numbers.parallelStream()
              .filter(i -> isPrime(i))
              .count();

Com praticamente nenhum esforço, apenas chamando um outro default method chamado parallelStream da classe Collection, que também fornece uma instância de Stream, habilitamos o paralelismo. Vamos ver se tivemos ganho de desempenho executando esse código:

 PT0.055318673S

Executando essa versão paralelizada, em um processador com 8 núcleos, utilizando Java 17, levou aproximadamente 0.055 segundos para executar a tarefa.

Bom, brincadeiras à parte, antes de comemorarmos essa performance, temos que admitir que um grande número de métricas de desempenho podem ser artificiais e não podemos confiar cegamente neles. O que esse exemplo quer demonstrar nada mais é que o uso de lambda expressions e o estilo funcional não significam desempenho ruim. Sempre ao criar código real para aplicações corporativas, devemos ficar de olho no desempenho e tratar as preocupações onde elas surgirem.

E é isso aí pessoal👍 ...

Estou curtindo demais ler o livro do renomado Venkat Subramaniam : "Functional Programming in Java: Harnessing the Power of Java 8 Lambda Expression" ³, então vou continuar a publicar mais blogposts com o intuido de fixar meu aprendizado e assim também ajudar quem interessar!

Espero que tenha gostado do texto! 😄

Se gostou e achou relevante esse conteúdo, compartilhe com seus amigos.😉

Críticas e sugestões serão sempre bem-vindos!!!

No próximo blogpost, vamos conhecer mais sobre Stream API, seu funcionamento, seu pipeline, suas operações e detalhes entre outras coisas...

Até a próxima!

Source dos exemplos ⁴:

Referências:

Estou usando JSR 354 Java Money. ↩
Javadoc - Package java.util.stream ↩
Livro - "Functional Programming in Java: Harnessing the Power of Java 8 Lambda Expression" by Venkat Subramaniam ↩
Estou usando JBang; ↩

[PT-BR] Collections, forEach, Lambda Expressions - o que são external ou internal iterators?

Maximillian Arruda — Mon, 15 Aug 2022 11:38:50 +0000

É muito comum utilizarmos estruturas de dados para nos ajudar a atender as necessidades requeridas em nossas aplicações. Uma dessas estruturas são as collections. Elas são tão comuns que remover até mesmo uma pequena quantidade de cerimônia para operá-las traria um grande ganho na redução de possíveis confusões que podem aparecer em nossos códigos.

Vamos explorar como podemos utilizar as Lambda Expressions para manipular essas tais coleções. Com elas podemos, de uma forma declarativa, filtrar dados, realizar transformações, criar novas coleções, concatenar elementos, entre outras operações.

Iterando em Coleções

Iterar por meio de uma lista é uma operação básica nas coleções (collection), e ao longo dos anos, essa operação também sofreu mudanças significativa dentro da linguagem Java.

Vamos começar com um exemplo - enumerando uma lista de nomes - utilizando uma abordagem mais antiga e seguir evoluindo até uma versão onde a escrita dessa operação apresente uma forma mais concisa e elegante.

Aqui criamos uma coleção imutável de lista de nomes:

  final List<String> developers = List.of(
              "Maximillian",
              "Otavio Santana",
              "Bruno Souza",
              "Elder Moraes",
              "Sérgio Lopes",
              "Fernando Boaglio");

Abaixo, uma forma de iterar e escrever cada item no console:

    for (int i = 0; i < developers.size(); i++) {
        System.out.println(developers.get(i));
    }

Provavelmente, alguma vez, durande a escrita de um laço for conforme escrito acima, vc se deparou questionando: é i < ou i <=. Essa abordagem é bem verbosa e propensa a erros, e outra, ela só é útil se precisarmos manipular elementos em um particular índice na coleção.

Uma outra forma que o Java também oferece do que o bom e velho for:

    for (String developer: developers) {
        System.out.println(developer);
    }

Por baixo do capô, essa forma utiliza a interface Iterator para iterar entre os itens, chamando o método hasNext para saber quando parar de iterar, e o método next para capturar o item na posição corrente.

Nesses dois casos, são utilizados iteradores externos (external iterators ¹).

No primeiro exemplo, precisamos explicitamente controlar a iteração, indicando onde começar e onde parar; Já no segundo, essas mesmas operações acontecem por baixo dos panos utilizando os métodos da interface Iterator. E mais, através desse controle explícito, podemos utilizar as declarações break e continue para gerenciar o fluxo de controle da execução da iteração.

Com external iterators, instruimos o programa COMO fazer a iteração para que, só então atingir o QUE queremos no final das contas.

Já no segundo exemplo, iteramos entre os elementos da coleção com menos cerimônia do que a primeira versão. Essa estrutura só é melhor do que a primeira quando não temos a intenção de acessar ou modificar a coleção baseada em índices e posições específicas , porém, ambas utilizam um estilo imperativo e nós podemos dispensar essa abordagem uma vez que podemos utilizar o estilo funcional.

Há boas razões a favor de mudar do estilo imperativo para o estilo funcional:

Loops utilizando for são inerentemente sequenciais e são difíceis de paralelizar;
Tais loops são non-polymorphic, isto é, temos que passar a coleção na instrução do for ao invés de executar algum método (que pode usufruir do polimorfismo por baixo dos panos) na coleção para executar a tarefa.
No nível de design, o princípio "Tell, don't ask"² cai por terra! Nós solicitamos a execução de uma específica iteração ao invés de deixar esses detalhes da iteração para a biblioteca de nível mais baixo.

Dito isso, vamos utilizar o estilo funcional no lugar do imperativo, e assim utilizar iteradores internos (internal iterators ¹).

Com uma internal iterators, nós deixamos a maioria das instruções de COMO fazer tal iteração para a biblioteca de nível mais baixo e focamos no QUE queremos realizar durante a iteração.

A interface Iterable foi melhorada no Java 8 com um método especial chamado forEach, que aceita um parâmetro do tipo Consumer. Como o próprio nome indica, uma instância do tipo Consumer irá consumir o que for passado pra ele através do seu método accept.

  developers.forEach(new Consumer<String>() {
      @Override
      public void accept(final String developer) {
          System.out.println(developer);
      }
  });

Ao trocar a utilização do velho for pelo novo internal iterator ¹ forEach ganhamos o benefício de não necessitar focar em como iterar na coleção em questão e sim em no que fazer a cada iteração. O código aplica o princípio Tell, don't ask de maneira satisfatória.

Espere um pouco, essa interface Consumer não é uma interface funcional!

Exato! Com isso podemos utilizar Lambda Expressions ao invés de implementar uma classe anônima!

O método forEach é um método que aplica o pilar higher-order function, onde nos permite oferecer uma Lambda Expression ou um bloco de código que irá executar dentro do contexto de cada elemento da lista. A variável developer será vinculada a cada elemento da coleção durante sua chamada.

Assim, a implementação por baixo dos panos deste método terá o controle de como iterar e como executar o objeto de função recebido como argumento. Encapsular a implementação atrás de métodos como esse permitem que implementações como essas possam também poderá decidir vários aspectos interessantes, como se a execução deve ser ou não preguiçosa (lazy), ou definir a ordem dos itens durante a iteração, ou até explorar o paralelismo como achar melhor. Esse é o poder do encapsulamento.

  developers.forEach((final String developer) -> 
                            System.out.println(developer));

A sintaxe padrão de Lambda Expressions espera que os parâmetros estejam junto com seu tipo definido entre parênteses e separado por vírgulas, mas o compilador Java também oferece a inferência de tipos ³ ⁴ ⁵.

Baseado na assinatura do método da interface que a Lambda Expression está implementando, o compilador é capaz de detectar qual é o tipo do parâmetro em questão e efetuar sua inferência.

Vamos usufruir da inferência de tipos em nosso exemplo tirando a declaração:

  developers.forEach((developer) -> 
                            System.out.println(developer));

Assim, baseado no contexto do método, o compilador sabe determinar o tipo do parâmetro que está sendo fornecido.

Para casos onde há multiplos parâmetros, podemos seguir o mesmo princípio, não declarar o tipo de cada parâmetro, mas se precisarmos especificar o tipo de um parâmetro, precisaremos especificar o tipo de todos os parâmentros, isto é, ou declara nenhum ou declara todos os tipos de cada parâmetros.

Para casos onde só há um parâmetro, o compilador Java não exige que o parâmetro esteja dentro de parenteses.

  developers.forEach(developer -> 
                            System.out.println(developer));

Mas uma resalva: parâmetros inferidos são non-final. Em um dos exemplos anteriores, escrevemos uma Lambda Expression onde além de explicitamente definir o tipo do parâmetro, nós também definimos que o parâmetro deve ser final. Isso instrui o compilador a nos alertar caso o parâmetro for modificado dentro da Lambda Expression. De modo geral, modificar parâmetros é algo ruim que pode conduzir a erros, então defini-los com final é uma boa prática.

Infelizmente, quando favorecemos a inferência de tipos na declaração dos parâmetros em uma Lambda Expressions, temos que ter uma disciplina extra em não modificar os parâmetros, pois o compilador não poderá nos ajudar nesses casos.

Reduzindo código com Method References

Vimos até agora exemplos com Lambda Expressions, porém há mais um passo que podemos dar para deixar o codigo mais conciso:

  developers.forEach(System.out::println);

No último código de exemplo nós usamos um Method Reference. O Java nos deixa, de maneira simples, substituir o corpo de código com um método nomeado de nossa escolha. Vamos olhar com mais detalhes sobre Method Reference em artigos futuros, no worries! 😉

Como não existe bala de prata, utilizar forEach também tem suas limitações. Uma vez que começa o método, diferentemente das versões que utilizam for, a iteração não podem ser interrompidas. Como consequência, esse estilo é útil em casos comuns onde nós queremos processar cada elemento de uma coleção.

No próximo artigo, vamos ver como Lambda Expressions podem nos ajudar a lidar com a mutabilidade e deixar nosso código mais conciso durante operações de transformação com coleções...spoiler: Streams API 🚀 !!!

Obrigado a todos e até o próximo artigo!!!

Source dos exemplos ⁶:

Iteration.java

Referências:

[PT-BR] Functional Interfaces, a fundação para a programação funcional com Java

Maximillian Arruda — Mon, 08 Aug 2022 13:04:18 +0000

No último post vimos como implementar o pattern EAM (Execute Around Method) no Java através das Lambdas Expressions, e vimos também que esse pattern utiliza um dos pilares da programação funcional chamado Higher-order functions para prover a sua solução.

É através dos objetos de função podemos aplicar o pilar Higher-order functions no Java, pois podemos:

Passar objetos de função como argumentos nos métodos;
Criar objetos de função dentro dos métodos e;
Retornar objetos de função de métodos;

Para escrever códigos que interajam com qualquer objeto, isso inclui os objetos de função, precisamos conhecer o seu tipo, o seu contrato. Comumente, utilizamos interfaces para definir esse contrato, que é onde definimos os métodos que podemos chamar das instâncias baseadas nas classes que implementam esse tal contrato. O mesmo acontece quando queremos interagir com uma váriavel, precisamos conhecer qual é o seu tipo.

Inevitavelmente, ao escrever nossos métodos precisamos definir, em suas assinaturas, os tipos dos argumentos que ele suporta e, se caso retornem algum objeto, precisamos também declarar qual é seu tipo. O mesmo se aplica a métodos que recebem ou devolvam objetos de função, isto é, será necessário declarar seu tipo, a sua interface.

Objetos de função que são criados através de lambda expressions ou method references (sim, vamos ver isso no futuro!😉), devem implementar interfaces especiais, as interfaces funcionais (Functional Interfaces).

As interfaces funcionais são interfaces que tem um único método abstrato para ser implementado e que podem ou não ter vários métodos estáticos ou default methods que estão implementados na própria interface.

Interfaces bem conhecidas Runnable, Callable, Comparable, entre outras que combinam com essa essa definição, são também tratadas como interfaces funcionais.

Você pode ficar atentado a criar suas interfaces funcionais, mas uma boa prática é utilizar as interfaces funcionais padrão fornecidas pelo pacote java.util.function¹ uma vez que alguma atenda sua necessidade.

As interfaces funcionais são a fundação para a utilização das Lambdas Expressions e Method References.

Conhecendo as interfaces funcionais mais utilizadas!

A biblioteca padrão do Java tem aproximadamente 43 interfaces funcionais no pacote java.util.function¹ para facilitar a vida do desenvolvedor.

Abaixo podemos conferir uma lista com seis interfaces básicas que frequentemente iremos encontrar e, por esse motivo, é importante ficarmos familiarizados com elas:

Consumer<T>
Supplier<T>
Predicate<T>
Function<T,R>
UnaryOperator<T>
BinaryOperator<T>

TL;DR

Há também três variantes para cada uma dessas seis interfaces funcionais básicas que operam com os seguintes tipos primitivos int, long e double. Essas são as Primitive Specializations².

As Primitive Specializations² foram adicionadas para remover a necessidade de se lidar com autoboxing³ e unboxing³ de tipos primitivos, e assim melhorar a performance da aplicação. Esses tipos não são parametrizados, exceto as variantes Function<T,R> que devem ser parametrizadas. Por exemplo: LongFunction<int[]> que recebe um long e retorna um int[].

A interface Function<T,R> tem nove variantes complementares que são utilizadas quando o tipo de retorno é primitivo. Já para funções que recebem o mesmo tipo como argumento e retorno, a interface UnaryOperator<T> entra na cena.

Para encontrar interfaces variantes complementares de Function<T,R> para retornos que resultem em primitivos, basta procurar interfaces onde o nome segue o padrão <Src>To<Result>Function, por exemplo, LongToIntFunction. Há seis variantes para essa condição.

Agora, para encontrar as interfaces variantes complementares de Function<T,R> para parâmetros do tipo primitivo porém o retorno uma referência para um objeto, basta procurar as interfaces onde o nome segue o padrão <Src>ToObjFunction, por exemplo, LongToObjFunction. Há três variantes para esse tipo de interface.

Há também variações especiais para Predicate<T>, Function<T,R> e Consumer<T> onde ambas aceitam dois argumentos: BiPredicate<T,U>, BiFunction<T,U> e BiConsumer<T,U>.

BiFunction<T,U> também tem variantes que retornam os três tipos primitivos relevantes: ToIntBiFunction<T,U>, ToLongBiFunction<T,U> e ToDoubleBiFunction<T,U>.

Já a interface BiConsumer<T,U> tem variações que recebem dois argumentos, uma referência de objeto e um tipo primitivo: ObjDoubleConsumer<T>, ObjLongConsumer<T> e ObjIntConsumer<T>, somando no total nove versões de dois argumentos das interfaces básicas.

Temos também a interface BooleanSupplier, uma variante de Supplier<T> que retorna um boolean.

Resumo das seis interfaces funcionais básicas

A maioria das interfaces funcionais padrões existe somente para fornecer suporte para os tipos primitivos, então:

Não ceda à tentação de usar as interfaces funcionais básicas com os tipos primitivos ao invés de utilizar as interfaces funcionais primitivas já existentes na biblioteca padrão. As consequências advindas da utilização do empacotamento dos tipos primitivos podem ser perigosíssimas para operações em massa. ⁴

Segue um resumo de cada uma das seis interfaces funcionais básicas:

Consumer<T>

Essa interface representa uma operação que vai aceitar um input do tipo T e não retornará nada (void).

método abstrato	`accept`
default method(s)	`andThen`
Uso comum	Como parâmetro em métodos `forEach`
Primitive Specializations²	`IntConsumer`, `LongConsumer`, `DoubleConsumer`,...