DEV Community: Paula Santana

Evite Classes Tagged

Paula Santana — Mon, 11 Sep 2023 17:45:13 +0000

Dê preferência às hierarquias de classes em vez das classes tagged.

Esta é uma série baseada no entendimento de tópicos relacionados ao livro com foco no resumo.

O que é uma classe Tagged?

São classes que representam mais de um tipo de objeto e utilizando um atributo que identifique qual o objeto foi instanciado.
Vamos ver o exemplo citado no livro Java Efetivo que torna mais clara essa afirmação.
Veja que a classe representa tanto um circulo quanto um retângulo e que alguns campos só fazem sentido quando é um dos tipos das instâncias.

Problemas

Muito Boilerplate
Campos de tag ( campos de tem objetivo de identificar o tipo da instância do objeto)
Legibilidade ruim, pois tem muitas particularidade para cada tipo
Uso desnecessário de memória, visto que nem todos os campos serão utilizados para cada tipo
Mais difícil o uso de campos final
Criação de muitos construtores
Maior possibilidade de erros de execução

Resumindo

Classes Tagged são verbosas, sujeitas a erros e ineficientes.
Se analisarmos bem as classes tagged são uma forma de estrutura do que poderia ser uma hierarquia de classes.
Então o livro mostra como seria refatorar o exemplo para o caminho certo, usando hierarquia.
Vamos ver?

Passos

De maneira bem sútil é orientada uma sequência de passos:

Criar uma classe abstrata com os métodos que não possuem comportamento diferente de acordo com o tipo
Criar as classes concretas, considerando cada tipo do campo tag para uma implementação diferente.

Resultado

A nova estrutura permite:

Diminuir boilerplate
Evitar erros de excução
Fácil entendimento
Campos final
Felixibilidade

Ou seja, sempre pense ao criar uma classe tagged se não seria melhor utilizar a hierarquia de classes.

Java Efetivo - Constantes

Paula Santana — Mon, 27 Feb 2023 20:07:14 +0000

Use as interfaces para definir tipos

Esta é uma série baseada no entendimento de tópicos relacionados ao livro com foco no resumo.

Interfaces

Sabemos que quando uma classe implementa uma interface, essa interface a qual ela implementou pode ser utilizada como um tipo.
Sempre precisamos ter em mente que ao criar uma interface podemos ter em mente o que será possível realizar com as instâncias das classes que a implementarem.
Vamos imaginar que temos classes que possuem um comportamente relacionado a pagamentos, ou seja, elas são pagáveis, isso indica que há classes que permitem ações relacionadas a esse assunto.

Não esta correto

O que não é considerado correto quando utilizamos interfaces.
Usarmos interfaces para qualquer outra coisa que não seja definir uma idéia do que seja possível realiza com as classes que a implementam.
Exemplo citado no livro é o de criação de "interface constante" onde o único objetivo é agrupamento de constantes para serem utilizadas por outras classes.
Essa abordagem não é considerada correta.

Isso porque interfaces deveriam conter constantes apenas para efeito de implementações internas e não para disponibilizar em suas implementações.
De qualquer forma há situações onde há precisaremos criar uma constante na interface e/ou classe e não devemos ter receio disso desde que realmente a constante esteja ligada diretamente com o propósito da classe e da interface.

Lembre-se

lembrando que a melhor maneira de criarmos constantes no Java são através de Enum ou como uma classe utilitária não instanciável.
E não considerando o uso de Interfaces para isso.
Interfaces devem ser utilizadas somente para definir tipos não para agrupamento de constantes.

Java Efetivo Essencial - Método Padrão

Paula Santana — Mon, 06 Feb 2023 21:45:19 +0000

Proteja as interfaces para a posteridade

_Esta é uma série baseada no entendimento de tópicos relacionados ao livro com foco no resumo.
_

Interfaces

Já sabemos que antes do Java 8 não era possível adicionar métodos sem gerra um quebra nas interfaces, ou seja, fazer com que todas as classes que implementasse a interfasse tivessem que implementar o novo método.
Com o Java 8 surgiram os métodos padrões, que permitem que adicionemos um método com implementação na interface, ou seja, nesse caso as classes que implementam a interface herdam o método padrão.
Porém é necessário que ter em mente que alterações em interfaces pode ser arriscado.

Atenção

Mesmo sendo possível adicionar o método padrão e ele ser utilizado por todas classes que implementam a interface não é possível ter controle de que a execução do método novo será com sucesso em todas as implementações.
O livro usa bastante exemplos da própria base de código do Java e então o exemplo citado sobre esse ponto é da interface de Collections, que teve métodos padrão implementados para que as lambdas fossem implementadas em todas as implementações de coleções.

Problemas

Um dos métodos implementados em Collections é o removeIf que não tem um efeito possitivo em todas implementações, como citado no livro algumas classes wraper por exemplo como a SynchronizedCollection da biblioteca Apache Commons acabam não executando bem esse método( pelo menos até a data de escrita do livro), isso porque quando um método padrão novo é implementado pode não conseguir atender todas as possibilidades de implementação. Então ao adicionarmos um método padrão precisamos ter em mente isso.

Então

Então devemos ficar atentos na execução do método nas implementações da interface.
E isso porque pode parece um recurso fácil de utilizar, mas ainda temos que garantir estabilidade na escrita de uma interface. Sempre se questione quando uma interface mudar muito, isso pode ser um problema no design da aplicação.
Tenha cautela ao projetar intefaces.

Resumo do Resumo

Métodos padrão são bons, mas devem ser utilizados em exceções em especial quando se tem noção das implementações da interface de modo que consiga projetá-lo bem.
Teste bem suas interfaces, implementando clientes das interfaces de forma totalmente diferente.
Corrigir erros depois de implementados em interfaces acaba sendo um trabaho mais difícil.

Java Efetivo Essencial - Interface

Paula Santana — Mon, 23 Jan 2023 20:11:41 +0000

Prefira as interfaces em vez das classes abstratas

Esta é uma série baseada no entendimento de tópicos relacionados ao livro com foco no resumo.

Interfaces

As interfaces são tipos abstratos, que utilizam a palavra reservada interface. Utilizadas para criar comportamentos que uma classe pode implementar. Antes apenas criávamos as assinaturas dos métodos nas interfaces, após o Java 8 houveram mudanças, como a implementação de métodos e atributos.
Interfaces permitem trabalharmos com polimorfismo no Java. Por regra uma classe pode implementar várias interfaces, caso o método não tenha implementação na interface é necessário fazer a implementação na classe que implementou a interface.

Classes Abstratas

É um tipo de classe no Java, no qual não será possível criar uma instância direta da mesma. Utilizamos a palavra reservada abstract para criarmos esse tipo de classe.
Tem o propósito apenas de criarmos uma estrutura de classe para que ela seja super classe de outras classes através herança.
Assim como regra de herança no Java, uma classe consegue apenas ter uma única super classe.

Vantagens

Existe uma grande vantagem em trabalharmos com interface, pois ao adicionar novas interfaces a uma classe já existente não impactamos no funcionamento e estrutura existentes.
Mas não acontece o mesmo quando tentamos adicionar uma classe abstrata nova em uma estrutura de classes existente.
Como uma classe pode implementar várias interfaces, mas não pode ter mais que uma super classe, trabalhar com interfaces acaba sendo mais fácil e maleável.

Misture

Antes do Java 8 não havia implementações de métodos, o que sugeria o uso de interfaces com classes abstratas para que fosse possível utilizar o mesmo dos dois mundos. Ainda assim o que me intrigou no livro é que utilizando de exemplos do Java manteve-se essa abordagem para implementação de métodos padrões, utilizando classes abstradas.
Como por exemplo a classe AbstractMapEntry que implementa a interface Map.Entry.

Resumo do Resumo

Trabalhar com interfaces é garantir flexibilidade no design do seu código.
Ainda sim é a melhor forma de trabalharmos com tipagem múltipla.
E se desejar implementar modelos prontos de implementação, utilize os recursos "novos" ( nem tão novos assim) que possibilitam implementação diretamente na interface.

Java Efetivo Essencial - HERANÇA

Paula Santana — Wed, 21 Dec 2022 14:18:53 +0000

Projete e documente as classes para herança ou a iniba

Esta é uma série baseada no entendimento de tópicos relacionados ao livro com foco no resumo.

Atenção

O tópico anterior alertou que podemos ter problemas ao trabalharmos com herança. Isso porque a subclasse acaba tendo poderes que podem interferir nos principios de design da classe, como por exemplo no encapsulamento.
Nesse tópico do livro vamos ver o que é interessante adotar caso trabalhe com herança ou como inibir o uso da mesma em seu código.

Documente

O primeiro ponto abordado nesse tópico do livro é sobre deixar claro através de documentação do método que pode ser sobrescrito em subclasses através da herança e os impactos que essa sobrescrita pode causar na execução do código.
Ele cita o usa da anotação @implSpec para determinar não só o que o método faz, mas como faz, o que pode não fazer sentido para você desenvolvedor, mas que pode evitar dores de cabeças futuras por sobrescritas de métodos em heranças.

Proteja

A outra abordagem adotada nesse ponto do livro é sobre proteger membros relacionados ao código que você quer garantir que não sejam sobrescritos.
Porém é interessante entender que nem sempre proteger alguns membros será positivo, o livro cita exemplos do próprio code base do Java, mas acredito que faça mais sentido falarmos de uma situação hipotética que você utilize no seu dia a dia.
Imagine você permitir sobrescrever um método mas não métodos que realizam cálculos com esse método sobrescrito, pode ser um problema.

Teste

O livro cita a importância de testar se o uso de herança em seu código esta adequado.
Para isso é recomendável escrever subclasses e entender o quanto o compartamento dessas quebram principios de design e quanto isso pode gerar falhas de segurança em seu código.
Outra forma também de perceber que ocultou algum item que era importante para execução do código da subclasse.

Restrições a considerar

Uma das restrições claras impostas nesse ponto é a utilização de métodos que podem ser sobrescritos nos construtores, não faça isso se você deseja que algum método seja sobrescrito.
Implementar as interfaces Cloenable e Serializable em classes que são projetadas para herança, pois isso impõe uma carga de implementação para os programadores que fizerem as subclasses. Existem formas de contornar esses pontos que são abordados em tópicos do livro ( caso queira mais detalhes vale ler a explicação completa pois não é possível adicionar em um simples resumo ok?)

Impedir

Não acho que o livro faça uma apologia a não usar herança mas traz a tona a preocupação de utilizar essa abordagem.
Realmente na maioria das vezes não projetamos classes pensando em herança e por isso é importante nesses casos garantir que se elas não foram projetadas para tal que não permitam subclasses.

Como impedir

A maneira mais simples de evitarmos que uma classes seja herdada é tornando ela final.
A outra forma seria tornando todos os construtores privados, pacotes privados e criando static factories no lugar de construtores públicos, é claro que ainda assim alguém diga que é possível utilizar de reflexão para isso, mas daí vamos e convenhamos que o desenvolvedor terá esforço para isso e estará claro que estará indo contra o design do código.

*Resumo do Resumo *

Não é simples construir uma classes pensando em herança.
Precisamos sempre evitar utilização de métodos que podem ser sobrescritos ou documentar o impacto deles para o código a ser herdado.
Sempre pensando que como construimos a classe principal poderá gerar impactos nas subclasses.

Java Efetivo Essencial - Composição

Paula Santana — Tue, 29 Nov 2022 21:02:56 +0000

Prefira a composição à herança

Esta é uma série baseada no entendimento de tópicos relacionados ao livro com foco no resumo.

A herança

No livro o primeiro ponto abordado no item que vamos falar nesse resumo é sobre o perigo do uso de Herança em Classes concretas, o autor deixa claro que não é relacionado a herança aplicada a interfaces e sim a quando uma classe estende outra, isso porque quando a herança ocorre em um contexto de pacotes controlado pode ser uma boa, porém, quando a herança passa além do pacote onde foi implementada, pode ser fácil de gerarmos problemas em nossa aplicação.

Pensando Bem...

Poucos sistemas que atuei utilizam herança e talvez você também já tenha percebido algo semelhante. No geral é mais comum usarmos apenas herança em interfaces e polimorfismo. Há discussões sobre se a herança deveria ser algo a se manter, mas ainda é uma abordagem que muitos aprendem e ficam se perguntando o porque de aprender e não utilizar tanto.

Problemas...

Um dos pontos é que ao utilizar herança violamos o princípio do encapsulamento visto que a subclasse depende dos detalhes da super classe para seu funcionamento e em caso de mudanças nessas implementações o impacto seria diretamente nas classes filhas. Lembrando que há situações que são exceções e que você pode projetar uma classe pensando nessas situações, mas a questão é que é possível ocorrer isso é um ponto de atenção em projetos que certamente diversas pessoas atuarão.

Composição

Como esse é um resumo do tópico vale ressaltar que no livro ele cita exemplos e mais problemas que podem decorrer do uso de Herança. Mas existe uma abordagem alternativa a herança que possivelmente você já viu em projetos Java!
O uso de composição de objetos, que é quando adicionamos um atributo privado que referencia a instância de outro objeto, o termo é usado dessa forma pois esse objeto será utilizado como um componente dentro da classe que esta sendo referenciado.
Isso porque na maioria dos casos, nossas classes necessitam de outras classes para realizar operações e não porque elas são subtipos de outra classe.
Além disso conseguimos projetar interfaces e comunicação especificas por classe e tratar problemas que podem ocorrer de maneira mais especifica.
Por exemplo, a Classe GerarRelatorio pode utilizar classes de uma biblioteca que gera arquivos de Excel, a nossa classe de relatório tem objetivo diferente e deseja tratar como criar o arquivo e resolver problemas que podem ocorrer de maneira específica.

Vantagens

Permite reutilização de código;
Permite compor um objeto com múltiplos objetos o que não é possível através de herança no Java;
Facilidade em executar e dividir os testes;
Flexibilidade para futuras implementações;

Atenção

Sempre é importante entender que a composição se tornará uma dependência a ser gerenciada e que é necessário garantir a consistência das dependências ao instanciar o objeto, ou seja, se sua classe A depende da classe B para fazer um processo garanta que ao instanciar a classe A seja obrigatório receber a instância da classe B.

Resumo do Resumo

Entendermos que apesar da herança ser uma abordagem muito famosa é também muito perigosa para o design de software.
O tópico do livro se concentra muito mais em falar do problemas da herança do que de fato da composição de objetos.
É aconselhado que dê preferência para composição de objetos em seus projetos Java.

Java Efetivo Essencial - Imutabilidade

Paula Santana — Thu, 13 Oct 2022 14:36:00 +0000

Reduza a mutabilidade das classes ao minimo

Esta é uma série baseada no entendimento de tópicos relacionados ao livro com foco no resumo.

Imutabilidade

Uma classe que não permite que suas instâncias sejam modificadas é considerada uma classe imutável. Ou seja, cada informação contida em um objeto durante seu ciclo de vida não é modificado.
Existe uma facilidade em projetar, implementar e utilizar classes IMUTÁVEIS, além de promover uma maior segurança e evitar muitos erros decorrente da alterações de objetos durante seu ciclo de vida.

Receita para classe Imutável

1 - Não forneça métodos que modifiquem o estado do objeto(mais conhecido como setters);
2 - Garanta que a classe não possa ser extendida(quando tornamos a classe final);
3 - Faça com que os campos/atributos sejam finais e privados;
4 - Não deixe que campos/atributos mutáveis sejam acessados por suas referências;

Na prática

Como Resolver
No caso anterior podemos realizar cópias defensivas, para gerarmos uma nova referência e não expor a referência que esta no objeto.

public Servico getServico() {
        Servico servicoRetorno = new Servico();
        return BeanUtils
           .copyProperties(servicoRetorno, servico);
}

Mais sobre

Os objetos imutáveis são thread-safe, não exigem sincronização, o que é muito posivito em cenários de paralelismo, ou seja, quando várias threads acessam o mesmo objeto simultâneamente.
É interessante também que essas classes podem implementar o método static factory e reutilizar instâncias existentes da mesma classe.

Vantagens

Os objetos imutáveis são ótimos para construir novos objetos. Pois garantimos que esse objeto não mudará.
Os objetos imutáveis fornecem atomicidade de falha de graça,pois o estado nunca muda, o que evita inconsistências geradas por mudanças no estado do objeto.

Desvantagens

Porém uma desvantagem é que muitas vezes quando precisamos fazer modificações do objeto, por ser imutável precisamos gerar cópia dele e por isso em cenários onde temos que realizar multiplas vezes alterações precisaremos gerar muitas cópias e isso dependendo do volume de objetos ser um ponto de atenção em relação a performance.

Finalizando

Nem sempre conseguimos garantir que a classe seja 100% imutável, mas restringirmos a mutabilidade pode ser uma boa abordagem.
Evite a criação de setters a menos que haja necessidade.
Em classes imutáveis precisamos garantir que os construtores recebam todas as informações para construir o objeto.

Java Efetivo Essencial - Acessibilidade de Classes e Membros

Paula Santana — Mon, 03 Oct 2022 21:29:59 +0000

Reduza ao mínimo a acessibilidade das classes e de seus membros

Esta é uma série baseada no entendimento de tópicos relacionados ao livro com foco no resumo.

Introdução

O livro cita que para identificarmos o quanto um componente é bem projetado em Java, precisamos analisar o quanto esse componente esconde seus dados internos e detalhes de implementação de outros componentes.
Isso porque quando pensamos no contexto de projetos Java, o ideal é termos componentes que ocultam os detalhes de implementação, fornecendo apenas sua API, um conceito de design de software mais conhecimento como encapsulamento.

Porque

Uma das vantagens que obtemos é o desacoplamento, ou seja, isso permite que os componentes sejam evoluidos, testados, otimizados, usados, etc de maneira isolada, não gerando impacto um no outro. Além de que componentes fracamente acoplados permitem que sejam utilizados em outros contextos.
Por fim acaba sendo um caminho com baixo risco na construção de sistemas grandes.

Como

Java possui controladores de acesso que permite controlarmos o acesso a classes, interfaces e membros.
Conhecemos como private, protected e public. E através desses modificadores podemos aplicar o encapsulamento, também chamado de ocultação de informação. O princípio básico diz: "faça com que cada classe ou membro seja o mais inacessível possível", ou seja, tentar utilizar o nível de acesso mais restrito.

Tipos de Acesso

Para classes e interfaces (não aninhadas) os niveis de acessos são publico e de pacote-privado.
Para membros de classes, como atributos, métodos, classes aninhadas e interfaces aninhadas é possível utilizar 4 níveis de acessos: privado, pacote-privado, protected e public.

Testes

Muitas vezes para facilitar os testes acabamos deixando membros das classes mais acessíveis, o que não é errado dependendo até que ponto estamos fazendo isso.
É aceitável transformar pacote-privado em privado de uma classe pública, mas inaceitável expor uma classe, interface ou membro em uma API para facilitar o teste.

Campos / Atributos

O livro enfatiza como atributos / campos de classes pública devem ser raramente públicos, pois quando o deixamos público estamos abrindo mão de limitar os valores que podem ser armazenados nele, isso pode ser um problema que elevaria a inconsistência de dados e de comportamento na execução do código.
O mesmo se aplica para campos final mutáveis que por si só já não são thread safe.
Isso acaba gerando falhas de segurança, especialmente porque apesar da referência do objeto não mudar o valor que contém nele pode. E devemos ter em mente que termos o getter ainda é uma forma que pode permitir alteração desse objeto através da referência.

Resumo

Esse tópico é mais simples, mas ainda muito infringido nos dias atuais, por isso um tema de extrema importância.
Quando projetar uma API e decidir o que será exposto através dela, você deve impedir que outro membros se tornem parte da implementação dela.
Uma classe pública deve evitar ao máximo expor seus membros e ter campos públicos, exceto constantes.
Garanta que objetos referenciados sejam imutáveis para evitar problemas futuros.

Java Efetivo Essencial - Comparable

Paula Santana — Sun, 18 Sep 2022 19:47:16 +0000

Pense na possibilidade de implementar o Comparable

Esta é uma série baseada no entendimento de tópicos relacionados ao livro com foco no resumo.

O que é

No Java quando desejamos fazer comparações entre classes de valor, fazemos com que essas classes implementem a interface Comparable ou Comparator.
Neste post vamos analisar mais sobre a interface Comparable que é abordada no livro Java Efetivo e que possui apenas um único método, o compareTo().

Comparable

Quando uma classe implementa essa Interface esta assumindo que há ordenação natural entre objetos da classe.
Além disso você permite que sua classe funcione com todos os algoritmos genéricos e com as implementações de coleções que dependem dessa interface como a TreeSet e TreeMap.
Se olharmos para as classes já existentes da plataforma Java, todas acabam implementando essa interface, além de que os Enums também por default implementam essa interface.

Como?

1-> Implementamos a interface Comparable
2-> Implementamos o Método compareTo()
3-> No método estou comparando o atributo nome que é uma String que já implementa também o método compareTo().
É importante termos em mente que para implementarmos esse método precisamos seguir um contrato geral.

Comparações

O contrato geral segue os seguintes itens:
1- Temos que garantir que na comparação onde temos dois objetos de comparação que se AA e se B>A, então A 2- Temos que garantir que se B>A e A>C então B>C
3- Se possível garantir que o resultado de comparação no compareTo seja semelhante o do equals.
4- Se o tipo comparado não for igual deve retornar ClassCastException
5- Se o tipo for nulo deve retornar NullPointerException.

Não é recomendado mais utilização de comparadores de valor < e > , existem métodos fluídos na implementação de Comparators após a versão 8 do Java.
Se um campo do objeto não implementar Comparable será necessário criar um Comparator desse tipo.
Se você deseja comparar múltiplos valores, a ordem a qual é comparada importa, sendo necessário sempre começarmos com os campos mais significativos.Sendo que se a comparação resultar em algo diferente de zero já pode retornar, se não continue comparando os próximos campos.

Acima vemos a aplicação da regra sobre comparação de múltiplos campos.

Em alguns casos podemos utilizar a criação de Comparators, no exemplo acima utilizamos como uma constante estática, utilizando os recursos que foram adicionados no Java 8, facilitamos muito o uso de comparações que envolvem múltiplos campos.

Resumindo
O livro aborda que quando é implementada uma classe de valor que exista uma ordenação para as instâncias que sejam implementadas a interface Comparable.
Procure usar sempre os métodos estáticos compare() que existem nos tipos primitivos empacotados ou use comparadores através da interface Comparator.

Java Efetivo Essencial - clone()

Paula Santana — Sun, 04 Sep 2022 17:26:02 +0000

Sobrescreva o clone de modo sensato

Esta é uma série baseada no entendimento de tópicos relacionados ao livro com foco no resumo.

Porquê?

Talvez você se questione porque você deveria entender sobre clonar objetos ou sobre como implementar o método clone nas classes. O fato é que muitas vezes precisaremos durante nosso código gerar objetos com mesmo conteúdo porém em uma outra instância na memória e muitas vezes esses objetos não são simples de serem instanciados, e aí onde o clone pode ser muito útil.
Dado isso vamos entender como implementamos o clone nos nossos objetos no Java.

Cloneable

Primeiro vamos entender a interface Cloneable que NÃO TEM nenhum método, isso porque ela é apenas utilizada para indicar que uma classe que implementa ela deve ter todos os atributos copiados para um novo objeto. Mas como isso ocorre?
Envolve o método clone() da classe Object que é herdado em todas as classes no Java, ou seja, além da classe herdar o método ao implementar essa interface ela garante que o comportamento desse método será modificado para cópia de cada atributo.

Como?

Para ser possível clonar a classe precisamos que ela implemente a interface Cloneable e que seja sobrescrito o método clone chamando o método através do super. Um ponto que deve ser levado em consieração é se uma superclasse já sobrescreveu esse método, pois neste caso não há necessidade de implementação, pois o clone funcionará normalmente.

Atenção!

Um dos conselhos que o livro trás é que mesmo o método originalmente retornar um Object, podemos modificar nossa sobrescrita do método pois por nosso tipo ser filho de Object será possível devido aos retornos covariantes do Java. Ou seja, garantimos de já retornarmos o tipo correto ao invés de deixarmos o cast para os clientes do método. Outro conselho é sobre tratar a exception com o try/catch porque a exceção do método clone é verificada, porém é quase impossível lançar a exceção e acaba obrigando os clientes a tratá-la.

Outro ponto que é necessário manter atenção, é sobre os tipos que são copiados, nesse caso o ideal é que seja feita a cópia do objeto através do método clone pois se não realizarmos isso estaremos apenas copiando a referência o que pode gerar inconsistências pois se a classe for mutável podemos realizar operações que impactariam o objeto origem. O mesmo deve ser realizado com coleções que estejam no objeto origem ou em sua estrutura. Como no exemplo acima, faço a cópia do campo serviço usando o clone dessa classe que de fato me retornará uma nova instância de Servico.
Quando falamos de cópias de objetos falamos de cópia simples ou profunda, a segunda esta ligada ao caso citado acima que envolve outros objetos na arvore de dependência.
Ainda nesse mesmo exemplo, se o atributo serviço fosse final, não seria possível realizar a operação de atribuição chamando o clone da classe Servico. Com isso podemos chegar a conclusão de que a estrutura de clone utilizada pela Cloneable não é compatível com situações como esta.

Conselhos

O livro aconselha que vale mais a pena fornecermos um método alternativo de cópia do objeto, através da criação de um método de cópia ou um método de fábrica de cópia que recebe como argumento a classe que tem o construtor de cópia, por exemplo:



//construtor
public Usuario(Usuaario usuario){...};
//método fabrica
public static Usuario newInstance(Usuario usuario){...};

As vantagens dessa abordagem são muitas, dentre elas: menor risco, não tem conflito com campos finais, não lança exceções verificadas, não precisa de cast, permite trabalhar com interface.

Use com cuidado...

O livro pede para evitarmos o uso da Cloneable e usarmos outras abordagens, mesmo considerando que em classes do tipo final o risco é menor. No geral não deveríamos trabalhar com cópia usando Cloneable, apenas para exceções como para cópia de arrays que são copiados de forma melhor com essa abordagem.
Cópias de objetos faz sentido para classes de dominío ou que representam objetos de transação e guardem estado.
E podemos implementar o método de cópia utilizando bibliotecas específicas para isso e não precisamos implementar a interface Cloneable nesse cenário.

Bibliotecas

No nosso dia a dia podemos trabalhar com objetos complexos que muitas vezes tem uma árvore de dependência de classes bem complicadas e daí não convém reinventarmos a roda e por isso blibliotecas como Apache Commons Lang, kostaskougios, fluidity-cloning são ótimas para utilizarmos para cópias de objetos e termos a garantia que elas realizam cópias profundas sem problemas.

Java Efetivo Essencial - toString()

Paula Santana — Mon, 29 Aug 2022 22:19:43 +0000

Sobrescreva sempre o toString

Esta é uma série baseada no entendimento de tópicos relacionados ao livro com foco no resumo.

Contextualizando

O método toString é um dos métodos que são herdados da classe Objetc.
A implementação desse método na classe Object é a seguinte :

public String toString() {
    return getClass().getName() + "@" + Integer.toHexString(hashCode());
}

Que é o nome da classe seguido de @ e do valor hexadecimal sem sinal do hashcode.

O porquê

Porque temos que nos preocupar? Pense bem, se formos utilizar a implementação padrão que imprime o objeto algo como :

br.com.conta.Usuario@c712a7ee

O quanto visualizar esse trecho em seu log pode ajudar a realizar debug do seu código de maneira eficiente?
Seria bem melhor visualizar os dados que identifiquem de fato o objeto, certo?

Exemplo

@Override
public String toString() {
    return "Usuario{" +
            "nome='" + nome + '\'' +
            ", email='" + email + '\'' +
            ", nascimento=" + nascimento +
            '}';
}

Acima sobrescrevemos o toString da classe Usuario por isso ela esta com a anotação @override.
Veja como esta muito mais legível e se logar o objeto iremos receber os dados no seguinte formato:

Usuario{nome='Ana dos Santos', email='anasantos10@gmail.com', nascimento=1977-08-15}

Hum...

Pode surgir uma dúvida que muitos devs acabam tendo referente a LGPD, pois dependendo do dado que o objeto guarda estado é perigoso registrarmos em logs, para isso é importante que você configure em sua dependência de logs mascaramento de alguns dados de logs, em alguns casos vale apena também verificar se faz sentido ter o dado no toString.
Não coloque valores que não são acessíveis da classe pois isso não auxiliaria no debug do objeto e faria com que uma informação restrita da classe fique visível.

O lado bom

A maioria das Ides permite que seja sobrescrito o toString de forma mais automática, por exemplo no Intellij temos a opção através do menu direito do mouse > generate > toString e aparece a tela para selecionarmos quais informações são necessárias para gerar o toString.

Nem sempre faz sentido...

Nem sempre os objetos de seu sistema terão objetivo de guardar estado como por exemplo um controller ou um service, neste caso não faz sentido sobrescrever o toString. Geralmente isso só faz sentido para classes de dominío ou que representam objetos de transação e guardem estado.
Outro ponto que deve ser levado em condieração é se uma superclasse já sobrescreveu esse método.

Java Efetivo Essencial - HashCode()

Paula Santana — Thu, 18 Aug 2022 14:08:00 +0000

Sobrescreva sempre o método Hashcode ao sobrescrever o método equals

Esta é uma série baseada no entendimento de tópicos relacionados ao livro com foco no resumo.

Entendendo

Assim como o método Equals(), o método Hashcode() também é herdado da classe Object.
Esse método é utilizado especialmente em estrutura de dados do Java, como na api de Collections e Map.
Em caso de você sobrescrever o Equals() e não sobrescrever o Hashcode() estará violando o contrato geral do método Hashcode() e implicará no mal funcionamento dessas estruturas de dados no Java.

Contrato Geral

Existem algumas regras que devem ser respitadas pelo método Hashcode():

Sempre que um método hashcode for executado repetidas vezes para o mesmo objeto deve sempre retornar o mesmo valor desde que nenhum dos dados usados no equals seja modificado;
Se dois objetos forem iguais através do método equals então o método hashcode desses objetos deve retornar o mesmo valor;
Se dois objetos não forem iguais no método equals(), não é necessário que o resultado do hashcode() seja diferente dos dois, porém é importante o programador entender que resultados diferentes melhora o desempenho de tabelas hash utilizadas nas estrutura de dados do Java;

Como deveria ser?

Não é preciso incluir campos do objeto não utilizado no método Equals().
Utilizar a mesma ordem dos campos possibilita uma função hash melhor.
Se calcularmos o Hash na mão o recomendado pelo livro é utilizar um número primo, como no exemplo abaixo:

@Override
public int hashCode() {
  int result = nome.hashCode();
  result = 31 * result + email.hashCode();
  result = 31 * result + nascimento.hashCode();
  return result;
}

Existem bibliotecas que realizam o calculo do hash de maneira mais segura, o livro recomenda o Guava do Google e também a da própria classe Objects do Java.
Ele traz apenas um alerta sobre o método da classe Objects em termos de performance.

@Override
public int hashCode() {
    return Objects.hash(nome, email, nascimento);
}

Se trabalha com classes Imutáveis uma abordagem seria o armazenamento do hashcode em cache para não ficar recalculando toda vez que o método for utilizado.

Concluindo

O livro ressalta a importância de utilizarmos todos os campos que são significativos para identificar o objeto, ou seja, mesmo que sejam muitos devemos manter eles e garantir que estes sejam presentes.

Entenda que sempre que sobrescrever um método será necessário sobrescrever o outro para que seu programa funcione corretamente.
Obdeça na sobrescrita as regras que esse método deve atender.

Algumas IDEs facilitam isso para o desenvolvedor como é o caso do Intellij que já possui uma opção em conjunto de sobrescrita dos dois itens.