Por que ter campos particulares, não é protegido o suficiente?

A visibilidade privatedos campos / propriedades / atributos da classe é útil? No OOP, mais cedo ou mais tarde, você criará uma subclasse de uma classe e, nesse caso, é bom entender e poder modificar completamente a implementação.

Uma das primeiras coisas que faço quando subclasses uma classe é alterar vários privatemétodos para protected. No entanto, esconder detalhes do mundo exterior é importante - portanto, precisamos protectede não apenas public.

Minha pergunta é: Você conhece um caso de uso importante em que, em privatevez de protectedser uma boa ferramenta, ou duas opções " protected& public" seriam suficientes para idiomas OOP?

Porque, como você diz, protectedainda deixa você com a capacidade de "modificar completamente a implementação". Não protege genuinamente nada dentro da classe.

Por que nos preocupamos em "proteger genuinamente" as coisas dentro da classe? Porque, caso contrário , seria impossível alterar os detalhes da implementação sem quebrar o código do cliente . Em outras palavras, as pessoas que escrevem subclasses também são "o mundo exterior" da pessoa que escreveu a classe base original.

Na prática, os protectedmembros são essencialmente uma "API pública para subclasses" da classe e precisam permanecer estáveis ​​e compatíveis com versões anteriores tanto quanto os publicmembros. Se não tivéssemos a capacidade de criar privatemembros verdadeiros , nada em uma implementação seria seguro para mudar, porque você não seria capaz de descartar a possibilidade de que o código do cliente (não malicioso) de alguma forma tenha conseguido depender isto.

Aliás, enquanto "No POO, mais cedo ou mais tarde, você fará uma subclasse de uma classe" é tecnicamente verdadeiro, seu argumento parece estar assumindo muito mais fortemente que "mais cedo ou mais tarde, você fará uma subclasse de toda classe ", o que quase certamente não é o caso.

No POO, mais cedo ou mais tarde, você fará uma subclasse de uma classe

Isto está errado. Nem todas as classes devem ser subclassificadas e algumas linguagens OOP de tipo estaticamente têm até recursos para evitá-la, por exemplo, final(Java e C ++) ou sealed(C #).

é bom entender e poder modificar completamente a implementação.

Não, não é. É bom que uma classe seja capaz de definir claramente sua interface pública e preservar seus invariantes, mesmo que sejam herdados.

Em geral, o controle de acesso é sobre compartimentação. Você deseja que uma parte individual do código seja entendida sem precisar entender em detalhes como ela interage com o restante do código. O acesso privado permite isso. Se tudo estiver ao menos protegido, você precisará entender o que cada subclasse faz para entender como a classe base funciona.

Ou, nos termos de Scott Meyers: partes particulares de uma classe são afetadas por uma quantidade finita de código: o código da própria classe.

As partes públicas são potencialmente afetadas por todo bit de código existente e todo bit de código ainda a ser gravado, que é uma quantidade infinita de código.

As partes protegidas são potencialmente afetadas por todas as subclasses existentes e todas as subclasses ainda a serem gravadas, o que também é uma quantidade infinita de código.

A conclusão é que o protegido oferece muito pouco mais que o público, enquanto o privado oferece um aprimoramento real. É a existência do especificador de acesso protegido que é questionável, não privado.

Sim, campos privados são absolutamente necessários. Apenas nesta semana, eu precisava escrever uma implementação de dicionário personalizada, onde eu controlava o que era colocado no dicionário. Se o campo do dicionário fosse tornado protegido ou público, os controles que eu escrevi com tanto cuidado poderiam ter sido facilmente contornados.

Os campos particulares geralmente fornecem garantias de que os dados são os esperados pelo codificador original. Torne tudo protegido / público e você montará um treinador e cavalos através desses procedimentos e validação.

Ao tentar argumentar formalmente sobre a correção de um programa Orientado a Objetos , é típico usar uma abordagem modular envolvendo invariantes de objetos . Nesta abordagem

1. Os métodos associaram a eles condições pré e pós (contratos).
2. Os objetos se associaram a eles invariantes.

O raciocínio modular sobre um objeto procede da seguinte forma (para uma primeira aproximação, pelo menos)

1. Prove que o construtor do objeto estabelece a invariante
2. Para cada método não privado, assuma que o objeto invariável e a pré-condição do método permanecem na entrada e, em seguida, prove que o corpo do código implica que a pós-condição e o invariante permanecem na saída do método

Imagine que verifiquemos object Ausando a abordagem acima. E agora deseja verificar method gdo object Bque chama method fde object A. O raciocínio modular nos permite raciocinar method gsem ter que reconsiderar a implementação de method f. Desde que possamos estabelecer a invariante object Ae a pré-condição method fno local da chamada method g,, podemos considerar a condição de postagem method fcomo um resumo do comportamento da chamada do método. Além disso, também saberemos que, após a chamada retornar, o invariante de Aainda se mantém.

Essa modularidade do raciocínio é o que nos permite pensar formalmente sobre grandes programas. Podemos raciocinar sobre cada um dos métodos individualmente e depois compor os resultados desse raciocínio, por sua vez, para raciocinar sobre partes maiores do programa.

Os campos particulares são muito úteis nesse processo. Para saber que a invariante de um objeto continua retida entre duas chamadas de método nesse objeto, normalmente contamos com o fato de que o objeto não é modificado no período intermediário.

Para que o raciocínio modular funcione em um contexto em que os objetos não possuam campos particulares, teríamos que ter alguma maneira de garantir que, independentemente do que um campo fosse definido por outro objeto, a invariante fosse sempre restabelecida (após o campo conjunto). É difícil imaginar um objeto invariável que ambos retenha, independentemente do valor que os campos do objeto tenham, e também é útil para raciocinar sobre a correção do programa. Provavelmente teríamos que inventar uma convenção complicada sobre o acesso ao campo. E provavelmente também perderá parte (na pior das hipóteses, toda) de nossa capacidade de raciocinar de forma modular.

Campos protegidos

Os campos protegidos restauram parte de nossa capacidade de raciocinar de forma modular. Dependendo do idioma, protectedpode restringir a capacidade de definir um campo para todas as subclasses ou todas as subclasses e classes do mesmo pacote. Geralmente, não temos acesso a todas as subclasses quando pensamos sobre a correção de um objeto que estamos escrevendo. Por exemplo, você pode escrever um componente ou biblioteca que mais tarde será usado em um programa maior (ou em vários programas maiores) - alguns dos quais talvez nem tenham sido gravados ainda. Normalmente, você não saberá se e de que maneira pode ser subclassificado.

No entanto, geralmente é uma responsabilidade de uma subclasse manter o objeto invariável da classe que ela estende. Portanto, em um idioma em que proteger significa apenas "subclasse", e onde somos disciplinados para garantir que as subclasses sempre mantenham os invariantes de sua superclasse, você poderia argumentar que a escolha de usar protegido em vez de privado perde apenas modularidade mínima .

Embora eu tenha falado sobre o raciocínio formal, muitas vezes se pensa que quando os programadores argumentam informalmente sobre a exatidão de seu código, às vezes também se apóiam em tipos semelhantes de argumentos.

privatevariáveis ​​em uma classe são melhores do que protectedpela mesma razão que uma breakinstrução dentro de um switchbloco é melhor que uma goto labelinstrução; que é que os programadores humanos são propensos a erros.

protectedAs variáveis ​​se prestam a abuso não intencional (erros de programadores), assim como a gotodeclaração se presta à criação de código espaguete.

É possível escrever código livre de erros usando protectedvariáveis ​​de classe? Sim, claro! Assim como é possível escrever código livre de erros usando goto; mas como diz o clichê "Só porque você pode, não significa que você deveria!"

As classes e, de fato, o paradigma OO, existem para se proteger contra infelizes programadores humanos propensos a erros que cometem erros. A defesa contra erros humanos é tão boa quanto as medidas defensivas incorporadas à classe. Fazer a implementação de sua classe protectedé o equivalente a abrir um enorme buraco nas paredes de uma fortaleza.

As classes base não têm absolutamente nenhum conhecimento das classes derivadas. No que diz respeito a uma classe base, protectedna verdade não oferece mais proteção do que public, porque não há nada que impeça uma classe derivada de criar um publicgetter / setter que se comporte como um backdoor.

Se uma classe base permite acesso sem impedimentos a seus detalhes internos de implementação, torna-se impossível para a própria classe se defender contra erros. As classes base não têm absolutamente nenhum conhecimento de suas classes derivadas e, portanto, não têm como se proteger contra os erros cometidos nessas classes derivadas.

A melhor coisa que uma classe base pode fazer é ocultar o máximo possível de sua implementação privatee impor restrições suficientes para impedir a quebra de alterações de classes derivadas ou qualquer outra coisa fora da classe.

Por fim, existem linguagens de alto nível para minimizar erros humanos. Boas práticas de programação (como os princípios do SOLID ) também existem para minimizar erros humanos.

Os desenvolvedores de software que ignoram as boas práticas de programação têm uma chance muito maior de falha e têm maior probabilidade de produzir soluções quebradas e não sustentáveis. Aqueles que seguem boas práticas têm uma chance muito menor de fracassar e têm maior probabilidade de produzir soluções que possam ser mantidas em funcionamento.

As classes herdáveis ​​têm dois contratos - um com detentores de referências a objetos e com classes derivadas. Membros públicos estão vinculados pelo contrato com titulares de referência e membros protegidos são vinculados pelo contrato com classes derivadas.

Tornar membros a protectedtorna uma classe base mais versátil, mas frequentemente limita as maneiras pelas quais as versões futuras da classe podem mudar. Criar membros privatepermite que o autor da classe tenha mais versatilidade para alterar o funcionamento interno da classe, mas limita os tipos de classes que podem ser úteis a partir dela.

Como exemplo, o List<T>.NET torna o armazenamento de backup privado; se protegidos, os tipos derivados poderiam fazer algumas coisas úteis que, de outra forma, não seriam possíveis, mas as versões futuras List<T>teriam para sempre usar seu armazenamento monolítico desajeitado, mesmo para listas que contêm milhões de itens. Tornar o armazenamento secundário privado permitiria que versões futuras List<T>usassem um armazenamento secundário mais eficiente sem interromper as classes derivadas.

Eu acho que há uma suposição fundamental no seu argumento de que, quando alguém escreve uma classe, não sabe quem pode estendê-la no futuro e por que motivo . Dada essa suposição, seu argumento faria todo o sentido, pois cada variável que você tornar privada poderia potencialmente cortar alguma avenida de desenvolvimento no caminho. No entanto, eu rejeitaria essa suposição.

Se essa suposição for rejeitada, haverá apenas dois casos a serem considerados.

1. O autor da classe original tinha idéias muito claras sobre por que ela pode ser estendida (por exemplo, é um BaseFoo e haverá várias implementações concretas de Foo no caminho).

Nesse caso, o autor sabe que alguém estenderá a classe e por que e, portanto, saberá exatamente o que proteger e o que tornar privado. Eles estão usando a distinção privada / protegida para comunicar uma espécie de interface ao usuário que cria a subclasse.

2. O autor da classe filho está tentando invadir algum comportamento em uma classe pai.

Esse caso deve ser raro (você pode argumentar que não é legítimo) e não é preferível apenas modificar a classe original na base de código original. Também pode ser um sintoma de mau design. Nesses casos, eu preferiria que a pessoa hackeie no comportamento, use outros hacks, como amigos (C / C ++) e setAccessible(true)(Java).

Eu acho que é seguro rejeitar essa suposição.

Isso geralmente volta à idéia de composição sobre herança . A herança geralmente é ensinada como uma maneira ideal de reduzir a reutilização de código, no entanto, raramente deve ser a primeira opção para reutilização de código. Eu não tenho um argumento simples e pode ser um pouco difícil e controverso de entender. No entanto, em minha experiência com modelagem de domínio, descobri que raramente uso herança sem ter uma compreensão muito clara de quem herdará minha classe e por quê.

Todos os três níveis de acesso têm seu caso de uso; o OOP estaria incompleto sem nenhum deles. Geralmente você faz

• torne todas as variáveis ​​/ membros de dados privados . Você não quer que alguém de fora mexa com seus dados internos. Também métodos que fornecem funcionalidade auxiliar (pense em cálculos com base em várias variáveis ​​de membro) à sua interface pública ou protegida - isto é apenas para uso interno e você pode querer alterá-lo / melhorá-lo no futuro.
• torne pública a interface geral da sua classe . É com isso que os usuários da sua classe original devem trabalhar e como você acha que as classes derivadas também devem ser. Para fornecer o encapsulamento adequado, geralmente são apenas métodos (e classes / estruturas auxiliares, enumerações, typedefs, o que o usuário precisar para trabalhar com seus métodos), não variáveis.
• declare os métodos protegidos que podem ser úteis para alguém que deseja estender / especializar a funcionalidade de sua classe, mas não deve fazer parte da interface pública - na verdade, você normalmente cria membros privados para protegidos quando necessário. Em caso de dúvida, não, até que você saiba que
  1. sua classe pode / pode / será subclassificada,
  2. e tenha uma ideia clara de quais podem ser os casos de uso da subclasse.

E você se desvia deste esquema geral apenas se houver uma boa razão ™ . Cuidado com "isso facilitará minha vida quando eu puder acessá-la livremente de fora" (e aqui fora também inclui subclasses). Quando implemento hierarquias de classes, geralmente começo com classes que não têm membros protegidos, até chegar a subclassificar / estender / especializá-las, tornando-me as classes base de um framework / kit de ferramentas e às vezes movendo parte de sua funcionalidade original para um nível acima.

Uma pergunta mais interessante, talvez, é por que qualquer outro tipo de campo além do privado é necessário. Quando uma subclasse precisa interagir com os dados de uma superclasse, isso cria diretamente um acoplamento direto entre os dois, enquanto o uso de métodos para proporcionar a interação entre os dois permite um nível de indireção que possibilita fazer alterações no superclasse que seria muito difícil.

Vários idiomas (por exemplo, Ruby e Smalltalk) não fornecem campos públicos, de modo que os desenvolvedores são desencorajados a permitir o acoplamento direto às implementações de classe, mas por que não ir além e ter apenas campos privados? Não haveria perda de generalidade (porque a superclasse sempre pode fornecer acessadores protegidos para a subclasse), mas garantiria que as classes sempre tenham pelo menos um pequeno grau de isolamento de suas subclasses. Por que esse design não é mais comum?

Muitas respostas boas aqui, mas de qualquer maneira eu colocarei meus dois centavos. :-)

Privado é bom pelo mesmo motivo que os dados globais são ruins.

Se uma classe declara dados privados, você sabe absolutamente que o único código que mexe com esses dados é o código da classe. Quando há um erro, você não precisa pesquisar por toda a criação para encontrar todos os lugares que possam alterar esses dados. Você sabe que está na aula. Quando você altera o código e altera algo sobre como esse campo é usado, não precisa rastrear todos os locais em potencial que podem usar esse campo e estudar se a alteração planejada os quebrará. Você sabe que os únicos lugares estão dentro da classe.

Tive muitas e muitas vezes que tive que fazer alterações nas classes que estão em uma biblioteca e usadas por vários aplicativos, e tenho que seguir com muito cuidado para garantir que não quebre nenhum aplicativo que não conheço nada. Quanto mais dados públicos e protegidos houver, maior o potencial de problemas.

Acho que vale a pena mencionar algumas opiniões divergentes.

Em teoria, é bom ter um nível de acesso controlado por todos os motivos mencionados em outras respostas.

Na prática, muitas vezes, ao revisar o código, vejo pessoas (que gostam de usar privado), alterando o nível de acesso de privado -> protegido e não com muita freqüência de protegido -> público. Quase sempre, a alteração das propriedades de classe envolve a modificação de setters / getters. Eles desperdiçaram muito do meu tempo (revisão de código) e deles (alteração de código).

Também me incomoda que isso signifique que suas classes não estão fechadas para modificação.

Isso ocorreu com o código interno, onde você sempre pode alterá-lo, se precisar também. A situação é pior com o código de terceiros quando não é tão fácil alterar o código.

Então, quantos programadores acham que é um aborrecimento? Bem, quantos estão usando linguagens de programação que não têm privado? Obviamente, as pessoas não estão apenas usando esses idiomas porque não possuem especificadores particulares, mas isso ajuda a simplificar os idiomas e a simplicidade é importante.

Imo é muito semelhante à digitação dinâmica / estática. Em teoria, a digitação estática é muito boa. Na prática, só previne como 2% de erros A Eficácia Unreasonable de Tipagem Dinâmica ... . O uso privado provavelmente evita erros menores que isso.

Eu acho que os princípios do SOLID são bons, desejo que as pessoas se importem mais com eles do que com a criação de uma classe com público, proteção e privacidade.

Eu também gostaria de adicionar outro exemplo prático do porquê protectednão é suficiente. Na minha universidade, os primeiros anos realizam um projeto no qual eles precisam desenvolver uma versão para desktop de um jogo de tabuleiro (para o qual uma IA é desenvolvida posteriormente e é conectada a outros jogadores através de uma rede). É fornecido algum código parcial para eles começarem, incluindo uma estrutura de teste. Algumas das propriedades da classe principal do jogo são expostas protectedpara que as classes de teste que estendem essa classe tenham acesso a elas. Mas esses campos não são informações confidenciais.

Como AT da unidade, muitas vezes vejo os alunos simplesmente criando todo o código adicionado protectedou public(talvez porque tenham visto o outro protectede outras publiccoisas e tenham assumido que deveriam seguir o exemplo). Pergunto a eles por que seu nível de proteção é inadequado e muitos não sabem o porquê. A resposta é que as informações confidenciais que eles estão expondo às subclasses significa que outro jogador pode trapacear simplesmente estendendo essa classe e acessando as informações altamente confidenciais do jogo (essencialmente o local oculto do oponente, eu acho semelhante ao que seria se você podia ver as peças dos seus oponentes em um tabuleiro de navios de guerra estendendo alguma classe). Isso torna seu código muito perigoso no contexto do jogo.

Fora isso, existem muitos outros motivos para manter algo particular até mesmo nas suas subclasses. Pode ser para ocultar detalhes de implementação que podem atrapalhar o funcionamento correto da classe, se alterados por alguém que não sabe necessariamente o que está fazendo (principalmente pensando em outras pessoas usando o seu código aqui).

Métodos / variáveis ​​particulares geralmente serão ocultados de uma subclasse. Isso pode ser uma coisa boa.

Um método privado pode fazer suposições sobre parâmetros e deixar a verificação de sanidade para o chamador.

Um método protegido deve verificar as entradas de sanidade.

"privado" significa: não se destina a ser alterado ou acessado por ninguém, exceto a própria classe. Não se destina a ser alterado ou acessado por subclasses. Subclasses? Quais subclasses? Você não deve subclassificar isso!

"protegido" significa: destinado apenas a ser alterado ou acessado por classes ou subclasses. Dedução provável que você deve subclassificar; caso contrário, por que "protegido" e não "privado"?

Há uma clara diferença aqui. Se eu tornar algo particular, você deve manter seus dedos sujos afastados. Mesmo se você for uma subclasse.

Uma das primeiras coisas que faço ao subclassificar uma classe é alterar vários métodos particulares para protegidos

Alguns argumentos sobre privatevs. protected métodos :

privatemétodos evitam 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 private seja pode ser visto como uma API fornecida pela classe ao "mundo exterior", no sentido de que subclasses de terceiros também são consideradas "mundo exterior", como alguém sugeriu em sua resposta já.

Isso é uma coisa ruim? - Acho que não.

Obviamente, uma API pública (pseudo-) bloqueia o programador original e dificulta a refatoração dessas interfaces. Mas, visto o contrário, por que um programador não deve projetar seus próprios "detalhes de implementação" de maneira tão limpa e estável quanto sua API pública? Ele deveria usar privatepara que ele possa ser desleixado ao estruturar seu código "privado"? Pensando que talvez ele pudesse limpá-lo mais tarde, porque ninguém notará? - Não.

O programador também deve pensar um pouco em seu código "privado", para estruturá-lo de uma maneira que permita ou promova a reutilização do máximo possível em primeiro lugar. Então, as partes não-privadas podem não se tornar tão onerosas no futuro quanto alguns temem.

Um monte de código (framework) Vejo adota o uso inconsistente de private: protected, métodos não-finais, que quase não fazem nada mais do que delegar a um método particular é comumente encontrado. protected, métodos não finais, cujo contrato só pode ser cumprido através do acesso direto a campos particulares também.

Esses métodos não podem ser substituídos / aprimorados logicamente, embora tecnicamente não exista nada para tornar isso (compilador) óbvio.

Quer extensão e herança? Não faça seus métodos private.

Não quer que certos comportamentos da sua classe sejam alterados? Faça seus métodos final.

Realmente não pode ter seu método chamado fora de um determinado contexto bem definido? Torne seu método privatee / ou pense em como você pode disponibilizar o contexto bem definido necessário para reutilização através de outro protectedmétodo de wrapper.

É por isso que eu advogo a usar privatecom moderação. E para não confundir privatecom final. - Se a implementação de um método é vital para o contrato geral da classe e, portanto, não deve ser substituída / substituída, faça-o final!

Para campos, privatenão é realmente ruim. Contanto que os campos possam ser razoavelmente "usados" através de métodos apropriados (isso não é getXX()ou setXX()!).

Você conhece um importante caso de uso em que privado, em vez de protegido, é uma boa ferramenta, ou duas opções "protected & public" seriam suficientes para idiomas OOP?

Privado : quando você tem algo que nunca será útil para qualquer subclasse chamar ou substituir.

Protegido : quando você tem algo que possui uma implementação / constante específica da subclasse.

Um exemplo:

public abstract Class MercedesBenz() extends Car {
  //Might be useful for subclasses to know about their customers
  protected Customer customer; 

  /* Each specific model has its own horn. 
     Therefore: protected, so that each subclass might implement it as they wish
  */
  protected abstract void honk();

  /* Taken from the car class. */
  @Override
  public void getTechSupport(){
     showMercedesBenzHQContactDetails(customer);
     automaticallyNotifyLocalDealer(customer);
  }

  /* 
     This isn't specific for any subclass.
     It is also not useful to call this from inside a subclass,
     because local dealers only want to be notified when a 
     customer wants tech support. 
   */
  private void automaticallyNotifyLocalDealer(){
    ...
  }
}

Foi difícil para mim entender esse assunto, então gostaria de compartilhar um pouco da minha experiência:

• Qual é o campo protegido ? É nada mais do que um campo, que não pode ser acessada fora de uma classe, ou seja publicamente como este: $classInstance->field. E o truque que é "é isso". As crianças da sua turma terão acesso total a ela, porque é a parte interna legítima delas.
• Qual é o campo privado ? É um " verdadeiro privado " para sua própria classe e sua própria implementação desta classe. "Manter fora do alcance das crianças", como no frasco de um medicamento. Você terá a garantia de que é irreversível pelos derivados da sua classe, seus métodos - quando chamados - terão exatamente o que você declarou

UPDATE: um exemplo prático de uma tarefa real que resolvi. Aqui está: você tem um token, como USB ou LPT (esse foi o meu caso), e você tem um middleware. O token solicita um código PIN, abre se estiver correto e você pode enviar parte criptografada e várias chaves para decifrar. As chaves são armazenadas em token, você não pode lê-las, apenas usá-las. E havia chaves temporárias para uma sessão, assinadas por uma chave em um token, mas armazenadas no próprio middleware. A chave temporária não deveria vazar para todo o lado de fora, apenas para existir no nível do driver. E usei um campo privado para armazenar essa chave temporária e alguns dados relacionados à conexão de hardware. Portanto, não derivados foram capazes de usar não apenas uma interface pública, mas também alguns protegidosSub-rotinas "práticas" que criei para uma tarefa, mas não foi possível abrir um cofre com as chaves e a interação HW. Faz sentido?