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.