¿Debo usar visibilidad interna o pública de forma predeterminada?

Lo que hiciste es exactamente lo que debes hacer; dale a tus clases la visibilidad más mínima que puedas. Heck, si usted quiere realmente ir cerdo entero, usted puede hacer todo internal (a lo sumo) y utilizar el InternalsVisibleTo atributo, para que pueda separar su funcionalidad pero aún así no exponerla al mundo exterior desconocido.

La única razón para hacer las cosas públicas es que estás empaquetando tu proyecto en varias DLL y / o EX y (por cualquier razón) no te importa usar InternalsVisibleTo, o está creando una biblioteca para uso de terceros. Pero incluso en una biblioteca para uso de terceros, debe tratar de reducir la "superficie" siempre que sea posible; cuantas más clases tenga disponibles, más confusa será su biblioteca.

En C#, una buena manera de asegurarse de que está utilizando la visibilidad mínima posible es dejar los modificadores de visibilidad hasta que los necesite. Todo en C# tiene por defecto la menor visibilidad posible: interno para las clases, y privado para miembros de la clase y clases internas.

Creo que deberías equivocarte del lado de las clases internas y los miembros. Siempre puede aumentar la visibilidad de un elemento, pero disminuirlo puede causar problemas. Esto es especialmente cierto si estás construyendo un marco para otros.

Debe tener cuidado de no ocultar la funcionalidad útil de sus usuarios. Hay muchos métodos útiles en. NET BCL que no se pueden usar sin recurrir a la reflexión. Sin embargo, al ocultar estos métodos, el área de superficie de lo que se debe probar y mantenido se reduce.

Prefiero evitar marcar las clases como public a menos que explícitamente quiera que mi cliente las consuma, y estoy preparado para apoyarlas.

En lugar de marcar una clase como internal, dejo la accesibilidad en blanco. De esta manera, public se destaca a la vista como algo notable. (La excepción, por supuesto, son las clases anidadas, que deben marcarse para que sean visibles incluso en el mismo ensamblado.)

La mayoría de las clases deben ser internal, pero la mayoría de los miembros no privados deben ser public.

La pregunta que debe hacerse sobre un miembro es "si la clase se hizo public ¿querría que el miembro fuera expuesto?". La respuesta suele ser "sí (así que public)" porque las clases sin ningún miembro accesible no son de mucha utilidad! internal los miembros tienen un papel; son 'acceso por puerta trasera' solo para familiares cercanos que viven en la misma asamblea.

Incluso si su clase permanece interna, es agradable ver cuáles son los miembros de la puerta delantera y cuáles son de la puerta trasera. Y si alguna vez lo cambias a público no vas a tener que volver atrás y pensar en cuáles son cuáles.

Debe tender a exponer lo menos posible a otras clases, y pensar cuidadosamente sobre lo que expone y por qué.

¿Hay alguna razón por la que necesite usar Interno en lugar de Privado? Te das cuenta de que el interno tiene un alcance de nivel de ensamblaje. En otras palabras, las clases/miembros internos son accesibles a todas las clases en un ensamblaje de varias clases.

Como algunas otras respuestas han dicho, en general ir para el más alto nivel de encapsulación como sea posible (es decir, privado) a menos que realmente necesita interno/protegido/público.

Encontré un problema usando las clases internas tanto como fue posible. No puede tener métodos, propiedades, campos, etc. de ese tipo (o tipo de parámetro o tipo de retorno) más visibles que internos. Esto lleva a tener constructores que son internos, así como propiedades. Esto no debería ser un problema, pero de hecho, cuando se utiliza Visual Studio y el diseñador xaml, hay problemas. Los errores falsos positivos son detectados por el diseñador debido al hecho de que los métodos son no es pública, las propiedades de control de usuario no parecen visibles para el diseñador. No se si otros ya han caído en tales asuntos...

Debe intentar hacerlos tan visibles como sea posible, pero como lo indicó Mike anteriormente, esto causa problemas con UserControls y el uso del VS Designer con esos controles en formularios u otros UserControls.

Como regla general, mantenga todas las clases y controles de usuario que no agregue usando el Diseñador solo tan visibles como sea necesario. Pero si está creando un control de usuario que desea usar en el Diseñador (incluso si está dentro del mismo ensamblaje), deberá asegurarse de que que la clase UserControl, su constructor predeterminado y cualquier Propiedad y Evento se hagan públicos para que el diseñador trabaje con ellos.

Tuve un problema recientemente donde el diseñador seguiría eliminando el esto.MyControl = nueva línea MyControl() del método InitializeComponent () porque el UserControl MyControl fue marcado como interno junto con su constructor.

Es realmente un error, creo que porque incluso si están marcados como internos, todavía aparecen en la caja de herramientas para agregar el Diseñador, o bien Microsoft solo necesita mostrar controles públicos con constructores públicos, o necesitan hacer que funcione con controles internos también.

Depende de cuánto control tengas sobre el código que lo consume. En mi desarrollo Java, hago todas mis cosas públicas finales por defecto porque los getters son molestos. Sin embargo, también tengo el lujo de poder cambiar cualquier cosa en mi base de código cuando quiera. En el pasado, cuando he tenido que liberar código a los consumidores, siempre he utilizado variables privadas y getters.

No elija una opción "predeterminada" que mejor se adapte a las necesidades de visibilidad de esa clase en particular. Cuando elige una nueva clase en Visual Studio, la plantilla se crea como:

class Class1
{
}

Que es privado (ya que no se especifica ningún ámbito). Depende de usted especificar el alcance de la clase (o dejarlo como privado). Debería haber una razón para exponer a la clase.

Me gusta exponer las cosas lo menos posible. Privado, protegido, interno, público: dé a las clases, variables, propiedades y funciones la menor cantidad de visibilidad que necesitan para que todo siga funcionando.

Subiré la visibilidad de algo por esa cadena hacia el público solo cuando haya una buena razón para hacerlo.

Estoy completamente en desacuerdo con las respuestas hasta ahora. Siento que internal es una idea horrible, evitando que otro ensamblado herede sus tipos, o incluso use sus tipos internos si surge la necesidad de una solución.

Hoy, tuve que usar la reflexión para llegar a los aspectos internos de un Sistema.Datos.DataTable (tengo que construir una datatable a la velocidad del rayo, sin todas sus comprobaciones), y tuve que usar reflexión, ya que no había un solo tipo disponible para mí; todos estaban marcados como interno.

Por defecto la clase se crea como interna en c#: medios internos: El acceso está limitado a la asamblea actual.

Véase http://msdn.microsoft.com/en-us/library/0b0thckt.aspx

Buen artículo el ámbito predeterminado es interno: http://www.c-sharpcorner.com/UploadFile/84c85b/default-scope-of-a-C-Sharp-class /