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

12

É 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?

— AJJ
fonte

2

Se você estiver criando alguma API, precisará antecipar a funcionalidade que um chamador pode precisar. Assim, você precisará pensar mais em seus modificadores de acesso. Depende de quem está usando o código que você está escrevendo.

— user2023861

Possível duplicata de Todas as suas variáveis precisam ser declaradas privadas?

— gnat

10

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.

— Ben Cottrell
fonte

Portanto, se eu tentar resumir o que você está dizendo de volta para você (para ver se eu entendo), é uma boa ideia pensar primeiro na interface pública (ou seja, como essa classe está realmente sendo usada pelo para começar?) e, em seguida, tornar todo o resto privado?

— AJJ 29/03

1

@ArukaJ Uma boa abordagem é escrever código que usará suas classes antes de criar a implementação. Isso pode ser um problema de galinha ou ovo até você começar a escrever os testes de unidade primeiro.

— JimmyJames 29/03

1

@ArukaJ Em geral, sim; o que a princípio pode parecer mais difícil de fazer, embora, como JimmyJames menciona, pareça muito mais intuitivo quando você estiver escrevendo testes de unidade. Pode envolver uma mentalidade um pouco diferente, mas o objetivo é pensar com mais cuidado sobre o que sua classe representa e como são suas entradas / saídas - no geral, essa é apenas uma maneira muito mais "OO" de pensar em design; maior probabilidade de resultar em classes ordenadamente encapsuladas com alta coesão.

— Ben Cottrell

Eu estou desconfiado de usar testes de unidade para projetar sua classe, porque os testes de unidade não são os que realmente o usarão. No entanto, eles são definitivamente melhores do que nada pensando em como a classe será usada.

— user949300

8

"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.

— gnasher729
fonte

Vamos dizer que você tem uma classe que você não pretende subclasse neste momento (e talvez nunca precise) e um método que, se você fosse a subclasse sua classe, seria útil / necessário para / pela subclasse. Você faria esse método privateou protected?

— Lfk

Deve ser a resposta aceita, tornar tudo privado a princípio parece que eu não quero pensar / projetar.

— Niing 23/05/19

1

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.

— Chris Ghyzel
fonte