¿Es una mala práctica de programación tener miembros "públicos" dentro de una clase "interna"?

Question

¿No sería más específico y apropiado si solo guardo miembros "protegidos", "internos" y "privados" (campo, método, propiedad, evento) en una clase que se declara como "interna"?

He visto esta práctica (tener miembros "públicos" en una clase "interna") en varios códigos, así que solo quería saber si es una mala práctica o si tiene algún beneficio o ventaja.

[Solo preocupado por C#] Gracias por su interés.

Answer 1

No necesariamente. Si desea implementar implícitamente una interfaz, los miembros públicos son más que aceptables.

En general, si la clase es interna, los miembros públicos no tienen mucho sentido. No te hará daño, ya que no podrás exponer la clase de una manera fuertemente tipada fuera del módulo en el que está definida, pero si no estás implementando implícitamente una interfaz, no hay mucha ventaja.

Answer 2

La especificación internal en la clase restringe el alcance de la declaración public en los miembros, por lo que todos sus miembros públicos son realmente internal. Dicho esto, public es mucho menos tipeo que internal, por lo que mi idioma habitual es declarar la clase como internal y los métodos expuestos como public. Solo marcó un miembro como internal si la clase es public y quiero restringir algunos miembros al mismo ensamblaje.

Answer 3

La única razón funcional de esto que conozco es la implementación implícita de interfaces. Todos los métodos de interfaz deben etiquetarse con public para coincidir con la interfaz. Esto es cierto incluso si el tipo o la interfaz no es pública.

Al margen de esta situación limitada, realmente no me gusta la práctica. Hacer esto hace que sea un poco más difícil grep para el área de superficie pública de su aplicación. En su lugar, debe hacer una búsqueda más avanzada.

Además, me molesta, probablemente de forma un poco irracional, que los miembros se marquen como públicos cuando en realidad no lo son.

Answer 4

Intento imaginar la posibilidad de que el modificador de acceso de clase cambie cuando establezco el modificador de método. Si un método necesita ser interno, incluso si la clase es pública, lo diré. Si no, entonces el método se escribe como público.

Answer 5

Eso es lo que hago. No puedo ayudarme a mí mismo, cuando mi cerebro piensa que "este miembro debe ser accesible", mis dedos comienzan a martillear incontrolablemente. No hay tal problema cuando declaro la clase sin embargo.

Una gran ventaja: una refactorización que hace que la clase interna sea pública (o al revés, preferiblemente) requiere cambiar solo una palabra. Y Microsoft también lo hizo, principalmente.

Answer 6

Es razonable suponer que estos miembros públicos todavía forman parte de la interfaz pública de la clase, incluso si la clase en sí tiene un alcance interno. Cuando veo internal en un miembro de la clase, esto me dice 'un acceso poco fiable de puerta trasera que expresa acoplamiento cerrado, mientras que public todavía implica responsabilidades de programación defensivas adecuadas en mi mente. Es puramente una distinción conceptual.

Answer 7

Yo diría que sí, es una mala práctica de programación.

No se trata solo de controlar el acceso. También se trata de hacer que el código sea más modular.

Si un consumidor de los datos de un objeto desea algunos de los datos de ese objeto, llama al método getter. Si, más tarde, los datos que se van a devolver deben ser diferentes, el programador solo necesita cambiar el código en un lugar en lugar de todos los lugares donde se leyeron esos datos (si el miembro era público). Esto es similar a por qué deberíamos escribir funciones/métodos y llamarlos en lugar de simplemente copiar y pegar el código sobre el lugar.

explicar con un ejemplo aquí: http://www.programmingincpp.com/private-versus-public-data-members-in-a-class.html