C # no es el único lenguaje de programación para .NET; otros idiomas pueden tener accesibilidad predeterminada diferente en varios contextos. La especificación private
dejará 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 private
o protected
no 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, Point
estructuras), 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.