¿Debería usar private en campos y métodos en C #?

Soy algo nuevo en C # y acabo de descubrir que: en C # todos los campos y métodos en una clase son privados por defecto. Lo que significa que esto:

class MyClass
{

string myString

}

es lo mismo que:

class MyClass
{

private string myString

}

Entonces, debido a que son los mismos, ¿debería usar la palabra clave private en los campos y métodos? Muchos ejemplos de código en línea usan la palabra clave private en su código, ¿por qué es eso?

Solo porque puede omitir saltos de línea e indentaciones y su compilador de C # todavía entenderá lo que quiere decirle, no es automáticamente una buena idea hacerlo.

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

es mucho menos legible para el lector humano que:

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

Y ese es todo el punto aquí: los programas están escritos para dos audiencias:

• El compilador o intérprete.
• Tú y otros programadores.

El último es el que necesita comprender y comprender rápidamente el significado de lo que está escrito. Debido a esto, hay algunas buenas prácticas que han surgido a lo largo de los años y son cuasi-normas más o menos comúnmente aceptadas. Una de ellas es poner palabras clave de alcance explícito, otro ejemplo es poner paréntesis adicionales alrededor de expresiones complejas, incluso en casos en los que no serían necesarios sintácticamente, como:

(2 + 5) & 4

C # no es el único lenguaje de programación para .NET; otros idiomas pueden tener accesibilidad predeterminada diferente en varios contextos. La especificación privatedejará en claro a cualquiera que lea el código que dicha accesibilidad está destinada, mientras que omitir la especificación deja abierta la pregunta de si el miembro podría haber sido, por ejemplo, destinado a ser utilizable dentro del ensamblado [como sería el valor predeterminado en VB.NET] . Ser explícito puede ser especialmente útil si uno usa múltiples idiomas con diferentes reglas.

Con respecto a si se debe favorecer privateo protectedno en ausencia de un argumento particularmente convincente a favor del otro, la decisión debe basarse en si es más probable que exponer a un miembro haga posible que una clase derivada haga algo útil que de lo contrario no sería posible, o que evitaría que futuras versiones de una clase modifiquen sus estructuras internas de datos de una manera que sería más eficiente. Uno puede ver ejemplos de ambas situaciones en List<T>.

En algunos casos, si uno tiene una lista de agregados (por ejemplo, Pointestructuras), puede ser útil actualizar los elementos en el lugar. Si se List<T>expone su almacén de respaldo a clases derivadas, se podría definir fácilmente EditableList<T>un método con:

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 luego se podría invocar usando algo como:

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

Tal método podría permitir actualizaciones eficientes incluso con tipos de estructura relativamente grandes [ya que no se requeriría copia]. El hecho de que List<T>no exponga sus componentes internos hace que sea imposible derivar una clase que pueda implementar dicho operador de manera eficiente.

Por otro lado, aunque hasta donde yo sé, Microsoft aún no ha explotado esta capacidad, tener la tienda de respaldo en privado permitiría que una versión futura de List<T>dividir la tienda de respaldo en partes que fueran menores de 85K cuando se usa la mayoría de los datos tipos, o más pequeños que 1000 artículos cuando se usa double. Tal división no sería posible si List<T>hubiera expuesto el almacén de respaldo a clases derivadas.

Sí, debe usarlo private:) La palabra clave se usa porque es una práctica generalmente aceptada y elimina todas las dudas sobre el alcance previsto de un miembro de la clase.

La legibilidad es muy importante con el código, especialmente cuando se trabaja en equipo. Si desea ver más la legibilidad del código, un buen libro de referencia que puedo recomendar es The Elements of C # Style .

Pregunta:

"¿Debería usar private en campos y métodos en C #?"

Respuesta rápida:

Sí, pero depende de la lógica de su código.

Respuesta extendida larga y aburrida:

Sugiero, siempre especifique la visibilidad para los miembros.

Creo que es un buen enfoque declarar miembros, por defecto, como "privados".

En el mundo real, uso "protegido" en su lugar.

Tarde o temprano, ese miembro oculto podría ser utilizado por una subclase.

A veces, una buena pregunta puede responderse mejor haciendo la pregunta opuesta.

La pregunta opuesta, a su pregunta, podría ser algo como:

"¿Debo usar siempre el modificador de acceso público en campos y métodos en C #"

En otros lenguajes de programación puede "promocionar" protegido al público, dependiendo de su diseño.

Utilizo muchas bibliotecas de jerarquía profunda de control (visual), donde se requieren algunos miembros (propiedades, métodos).

A veces, es mejor tenerlos públicos, a veces no.