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.
Top comments (0)