Pregunta

Soy un desarrollador bastante nuevo de C# y .Net.Recientemente creé un complemento MMC usando C# y me alegró lo fácil que fue hacerlo, especialmente después de escuchar muchas historias de terror de otros desarrolladores de mi organización sobre lo difícil que es hacerlo en C++.

Prácticamente revisé todo el proyecto en algún momento e hice que cada instancia de la palabra clave "pública" fuera "interna", excepto cuando lo requiera el tiempo de ejecución para ejecutar el complemento.¿Cuál es su opinión al respecto? ¿Deberían, en general, hacer que las clases y los métodos sean públicos o internos?

¿Fue útil?

Solución

Creo en las cajas negras siempre que sea posible.Como programador, quiero una caja negra bien definida que pueda colocar fácilmente en mis sistemas y hacer que funcione.Le doy valores, llamo a los métodos apropiados y luego obtengo mis resultados.

Para ello, dame solo la funcionalidad que la clase necesita exponer para funcionar.

Considere un ascensor.Para que llegue al piso, presiono un botón.Esa es la interfaz pública de la caja negra que activa todas las funciones necesarias para llevar el ascensor al piso deseado.

Otros consejos

Lo que hiciste es exactamente lo que debes hacer;Dale a tus clases la menor visibilidad posible.Diablos, si realmente quieres hacerlo todo, puedes hacer todo internal (como máximo) 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á empaquetando su proyecto en varias DLL y/o EXE y (por el motivo que sea) no le interesa utilizar InternalsVisibleTo, o está creando una biblioteca para uso de terceros.Pero incluso en una biblioteca para uso de terceros, debe intentar reducir el "área de superficie" siempre que sea posible;Cuantas más clases tengas disponibles, más confusa será tu biblioteca.

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

Creo que deberías pecar del lado de las clases y miembros internos.Siempre puedes aumentar la visibilidad de un elemento, pero disminuirla puede causar problemas.Esto es especialmente cierto si estás creando un marco para otros.

Sin embargo, debe tener cuidado de no ocultar funciones útiles a sus usuarios.Hay muchos métodos útiles en .NET BCL que no se pueden utilizar sin recurrir a la reflexión.Sin embargo, al ocultar estos métodos se reduce la superficie de lo que se debe probar y mantener.

Prefiero evitar marcar clases como public a menos que quiera explícitamente que mi cliente los consuma y esté preparado para apoyarlos.

En lugar de marcar una clase como internal, dejo en blanco la accesibilidad.Por aquí, public 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 ensamblaje).

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

La pregunta que debes hacerte sobre un miembro es "si la clase estuviera hecha public ¿Me gustaría que el miembro estuviera expuesto?".La respuesta suele ser "sí" (entonces public)" porque las clases sin miembros accesibles no son de mucha utilidad.internal los miembros tienen un papel;son 'acceso por la puerta trasera' destinados únicamente a parientes cercanos que viven en la misma asamblea.

Incluso si su clase sigue siendo interna, es bueno ver cuáles son miembros de la puerta de entrada y cuáles de la puerta de atrás.Y si alguna vez lo cambia a público, no tendrá que volver atrás y pensar cuáles son cuáles.

Debería tender a exponerse lo menos posible a otras clases y pensar detenidamente qué expone y por qué.

¿Hay algún motivo por el que necesite utilizar Interno en lugar de Privado?Te das cuenta de que Internal tiene un alcance de nivel de ensamblaje.En otras palabras, las clases/miembros internos son accesibles para todas las clases en un ensamblaje de varias clases.

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

Encontre un problema al usar clases internas cuanto más se pueda.No puede tener métodos, propiedades, campos, etc. de ese tipo (o tipo de parámetro o tipo de retorno) más visibles que los internos.Esto lleva a tener constructores que son internos, así como propiedades.Esto no debería ser un problema, pero de hecho, cuando se usa 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 no son públicos, las propiedades de control del usuario no parecen visibles para el diseñador.No sé si otros ya han caído en temas así...

Debería intentar hacerlos lo más visibles posible, pero como lo indicó Mike anteriormente, esto causa problemas con los controles de usuario y el uso de VS Designer con esos controles en formularios u otros controles de usuario.

Entonces, 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 UserControl que desea usar en el Diseñador (incluso si está dentro del mismo ensamblaje), deberá asegurarse de que la clase UserControl, su constructor predeterminado y todas las Propiedades y Eventos se hagan públicos para el diseñador. para trabajar con ello.

Recientemente tuve un problema en el que el diseñador seguía eliminando la línea this.myControl = new MyControl() del método InitializeComponent() porque UserControl MyControl estaba marcado como interno junto con su constructor.

Creo que es realmente un error porque incluso si están marcados como internos, todavía aparecen en la Caja de herramientas para agregarlos en el Diseñador, o Microsoft solo necesita mostrar controles públicos con constructores públicos, o deben hacerlo funcionar con controles internos como Bueno.

Depende de cuánto control tengas sobre el código que lo consume.En mi desarrollo de Java, hago que todas mis cosas sean públicas finales de forma predeterminada porque los captadores son molestos.Sin embargo, también tengo el lujo de poder cambiar cualquier cosa en mi código base cuando quiera.En el pasado, cuando tenía que entregar código a los consumidores, siempre usaba variables privadas y captadores.

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 alcance).Depende de usted especificar el alcance de la clase (o dejarla como privada).Debería haber una razón para exponer la clase.

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

Aumentaré la visibilidad de algo en esa cadena hacia el público sólo cuando haya una buena razón para hacerlo.

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

Hoy, tuve que usar la reflexión para llegar a las partes internas de System.Data.DataTable (tengo que construir una tabla de datos a la velocidad del rayo, sin todas sus comprobaciones), y tuve que usar la reflexión, ya que ni un solo tipo estaba disponible para mí;todos estaban marcados como internos.

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

verhttp://msdn.microsoft.com/en-us/library/0b0thckt.aspx

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

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top