One of the first things I do when I subclass a class is to change a
bunch of private methods to protected
Algum raciocínio sobre os métodos private
vs. protected
:
private
métodos impedem a reutilização de código. Uma subclasse não pode usar o código no método privado e pode ter que implementá-lo novamente - ou reimplementar o (s) método (s) que originalmente dependem do método privado & c.
Por outro lado, qualquer método que não seja private
pode ser visto como uma API fornecida pela classe para "o mundo externo", no sentido de que subclasses de terceiros são consideradas "mundo exterior" também, como alguém sugeriu em sua resposta já.
Isso é uma coisa ruim? - Eu não penso assim.
Naturalmente, uma API (pseudo) pública bloqueia o programador original e impede a refatoração dessas interfaces. Mas, ao contrário, por que um programador não deveria projetar seus próprios "detalhes de implementação" de uma maneira tão limpa e estável quanto sua API pública? Ele deve usar private
para que ele possa ser desleixado sobre a estruturação de seu código "privado"? Pensando talvez que ele poderia limpá-lo mais tarde, porque ninguém vai notar? - Não.
O programador deve colocar um pouco de reflexão em seu código "privado" também, para estruturá-lo de uma forma que permita ou até mesmo promova a reutilização do máximo possível, em primeiro lugar. Então, as partes não privadas podem não se tornar um fardo no futuro, como alguns temem.
Um monte de código (framework) que vejo adota um uso inconsistente de private
: protected
, métodos não finais que mal fazem mais do que delegar a um método privado são comumente encontrados. protected
, métodos não finais cujo contrato só pode ser cumprido através do acesso direto a campos privados também.
Esses métodos não podem ser logicamente substituídos / aprimorados, embora tecnicamente não haja nada lá para tornar isso (compilador) óbvio.
Deseja extensão e herança? Não faça seus métodos private
.
Não quer que determinado comportamento de sua classe seja alterado? Faça seus métodos final
.
Realmente não pode ter seu método chamado fora de um contexto certo e bem definido? Faça seu método private
e / ou pense em como você pode disponibilizar o contexto bem definido necessário para reutilização por meio de outro método% wrapper protected
.
É por isso que defendo usar private
com parcimônia. E para não confundir private
com final
. - Se a implementação de um método é vital para o contrato geral da classe e, portanto, não deve ser substituído / substituído, torne-o final
!
Para campos, private
não é muito ruim. Contanto que o (s) campo (s) possa (m) ser razoavelmente "usado (s)" por meio de métodos apropriados (isso não é getXX()
ou setXX()
!).