Práticas recomendadas para o uso público, protegido e privado?

É justo dizer que é uma boa prática deixar tudo como padrão private antemão ao codificar alguma coisa?

E, em seguida, atualize-o apenas protectedse uma subclasse precisar ou publicse outra classe precisar?

Resposta curta: Sim

Resposta mais longa:

Sim, mas isso não deve ser interpretado como uma sugestão para começar escrevendo suas aulas com tudo privado; essa abordagem implica no design da classe, concentrando-se nos detalhes da implementação antes de você escolher uma interface.

Um dos aspectos mais importantes a considerar ao projetar uma classe é como ela será usada; que envolve pensar em seus métodos públicos antes de começar a pensar em detalhes particulares / de implementação.

Além disso, essa abordagem geralmente perde chances de se perguntar "Como eu escreveria um teste de unidade para esta classe?" - que é uma pergunta importante a ser feita, mesmo se você não estiver escrevendo testes de unidade. (Relacionado: "Quais são os princípios de design que promovem código testável?" )

Portanto, depois de definir a interface pública, é uma boa idéia padronizar o restante para privado, porque a maior parte será tipicamente detalhes detalhados da implementação, o que não interessa a nada fora da classe.

"E somente atualize para protegido se uma subclasse precisar, ou public se outra classe precisar?"

Essa é a abordagem errada. No momento do design, você deve saber qual acesso público deseja dar. Geralmente, você dá acesso público, porque esse é o objetivo de sua classe. E você fornece acesso protegido porque deseja que as subclasses acessem as coisas. E você usa privado para coisas que não são da conta de mais ninguém.

Agora, se alguém precisar acessar coisas que não pode acessar, pense bastante sobre essa necessidade . Eles não precisam desse acesso, ou seu design está errado. Talvez seu design esteja errado e algo não seja público que deva ser público, então você muda isso. Mas se o seu design é certo, então há algo errado com a necessidade , para que corrigir isso , em vez de danificar o seu design.

A chave para entender esse aspecto da programação orientada a objetos é o conceito de encapsulamento de dados . A idéia é facilitar a compreensão de uma classe ocultando seus detalhes de implementação. Isso é chamado de ocultação de dados . Assim, queremos apenas expor (tornar públicas) as funções necessárias para usar a classe. Essas funções são a interface para a classe.

Pense em uma interface como o volante de um carro. Você decide em qual direção o carro vai girando o volante, mas por baixo das tampas existem válvulas rotativas, hidráulica, polias alterando a rotação de suas rodas, mas você não precisa de um engenheiro mecânico para dirigir um carro.

Portanto, a resposta para sua pergunta é sim. Você deseja ocultar o máximo de detalhes sobre uma classe de outras classes possível. É fácil aprender quando algo deve ser público, privado ou protegido, mas difícil de dominar.