Você deve usar privado em campos e métodos em c #?

Eu sou um pouco novo em C # e acabei de descobrir que: em C # todos os campos e métodos em uma classe são privados por padrão. Significando que isso:

class MyClass
{

string myString

}

é o mesmo que:

class MyClass
{

private string myString

}

Então, como são iguais, devo usar a palavra-chave private em campos e métodos? Muitos exemplos de código online usam a palavra-chave private em seu código, por que isso?

Só porque você pode omitir feeds de linha e recuos e seu compilador C # ainda entenderá o que você quer dizer, não é automaticamente uma boa ideia fazer isso.

using System; namespace HelloWorld{class 
Hello{static void Main(){Console.WriteLine
("Hello World!");}}}

é muito menos legível para o leitor humano do que:

using System;
namespace HelloWorld
{
    class Hello 
    {
        static void Main() 
        {
            Console.WriteLine("Hello World!");
        }
    }
}

E esse é o ponto aqui: os programas são escritos para dois públicos:

• O compilador ou intérprete.
• Você e outros programadores.

O último é aquele que precisa entender e compreender rapidamente o significado do que está escrito. Por esse motivo, existem algumas boas práticas que surgiram ao longo dos anos e são quase ou quase-padrões geralmente aceitos. Uma delas é colocar palavras-chave de escopo explícitas, outro exemplo é colocar parênteses extras em torno de expressões complexas, mesmo nos casos em que elas não seriam necessárias sintaticamente, como:

(2 + 5) & 4

C # não é a única linguagem de programação para .NET; outros idiomas podem e têm acessibilidade padrão diferente em vários contextos. A especificação privatedeixará claro para quem ler o código que essa acessibilidade é pretendida, enquanto a omissão da especificação deixa em aberto a questão de saber se o membro pode ter sido, por exemplo, destinado a ser usado dentro do assembly [como seria o padrão no VB.NET] . Ser explícito pode ser especialmente útil se você usar vários idiomas com regras diferentes.

Com relação a se deve privateou protectednão ser favorecido na ausência de um argumento particularmente convincente a favor do outro, a decisão deve se basear em se é mais provável que a exposição de um membro torne possível a uma classe derivada fazer algo útil que caso contrário, não seria possível ou impediria que versões futuras de uma classe modificassem suas estruturas de dados internas de uma maneira que fosse mais eficiente. Pode-se ver exemplos de ambas as situações em List<T>.

Em alguns casos, se houver uma lista de agregados (por exemplo, Pointestruturas), pode ser útil atualizar itens no local. Se List<T>exposto seu armazenamento de suporte a classes derivadas, pode-se definir facilmente um EditableList<T>com um método:

delegate void ActByRef<T1,T2>(ref T1 p1, ref T2 p2);

void ActOnItem<TParam>(int index, ref TParam param, ActByRef<TParam> proc)
{
  .. test index, then...
  proc(ref _arr[index], ref proc);
}

que poderia então ser chamado usando algo como:

int adjustmentAmount = ...;
myList.ActOnItem(index, ref adjustmentAmount, 
  (ref Point pt, ref int dx) => pt.X += dx );

Esse método pode permitir atualizações eficientes, mesmo com tipos de estrutura relativamente grandes [já que nenhuma cópia seria necessária]. O fato de List<T>não expor seus componentes internos torna impossível derivar uma classe que poderia implementar esse operador com eficiência.

Por outro lado, embora, até onde eu saiba, a Microsoft ainda não tenha explorado essa capacidade, ter o armazenamento secundário privado tornaria possível para uma versão futura List<T>dividir o armazenamento secundário em partes menores que 85K ao usar a maioria dos dados. tipos ou menores que 1000 itens ao usar double. Essa divisão não seria possível se List<T>houvesse exposto o armazenamento de suporte a classes derivadas.

Sim, você deve usá-lo private:) A palavra-chave é usada porque geralmente é uma prática aceita e remove todas as dúvidas sobre o escopo pretendido de um aluno.

A legibilidade é muito importante com o código, especialmente quando se trabalha em equipe. Se você quiser examinar melhor a legibilidade do código, um bom livro de referência que posso recomendar é The Elements of C # Style .

Questão:

"Você deve usar privado em campos e métodos em C #?"

Resposta rápida:

Sim, mas isso depende da sua lógica de código.

Resposta estendida longa e chata:

Sugiro, sempre especifique a vissibilidade dos membros.

Eu acho que é uma boa abordagem declarar membros, por padrão, como "particulares".

No mundo real, eu uso "protegido".

Mais cedo ou mais tarde, esse membro oculto pode ser usado por uma subclasse.

Às vezes, uma boa pergunta pode ser melhor respondida, fazendo a pergunta oposta.

A pergunta oposta, à sua pergunta, pode ser algo como:

"Devo usar sempre modificador de acesso público em campos e métodos em C #"

Em outras linguagens de programação, você pode "promover" protegido ao público, dependendo do seu design.

Eu uso muitas bibliotecas de hierarquia profunda de controle (visual), onde alguns membros (propriedades, methos) são necessários.

Às vezes, é melhor tê-los em público, às vezes não.