¿Cómo decidir si un método será privado, protegido, interno o público?

Question

Estoy diseñando una clase donde algunos métodos no causarán ningún daño si se exponen como públicos. Pero también pueden ser privados, ya que se usarán solo de la misma clase en mi proyecto.

de hacerlos públicos tiene las siguientes ventajas:

1. Unidad comprobable sin la necesidad de métodos de acceso.
2. Flexibilidad.

Haciéndolos privada tiene las siguientes ventajas:

1. documentación pública simplificación.
2. Algunos errores desconocidos no están expuestos.

¿Cuáles son las pautas generales en este caso?

Answer 1

Oh, por favor lea el cap. 06 Of Code Complete 2 de Steve McConnell, si tiene acceso a él. Eso responderá a tu pregunta perfectamente.

En general, si el Método se ajusta a la "Persona" general de la clase, hágalo público. Más técnicamente, intenta no romper la abstracción. Hubiera dado un ejemplo, pero no conozco el contexto de su trabajo, por lo que los ejemplos pueden ser irrelevantes.

Si no lo necesita, no hay necesidad de hacer público un Método.

Para realizar pruebas, +1 a lijadoras John.

Pero realmente no puedo explicarte aquí como Steve ha explicado en CC2.

Espero que esté bien para publicar referencias de libro en Satckoverflow? (Coméntelo.)

Answer 2

En este caso, generalmente los haré lo más privados posible, y luego promover su accesibilidad cuando surja la necesidad (por ejemplo, el código de otras clases se beneficiaría de poder acceder a esos métodos directamente). Es fácil agregar métodos a una API y mucho más difícil eliminarlos (sin romper otro código).

Answer 3

Siempre haga todo lo más privado posible.

Para las pruebas de unidad, que a veces crea un miembro interna, a continuación, utilizar el atributo InternalsVisibleTo en los AssemblyInfo.cs para permitir la prueba de unidad de acceso de montaje a los miembros internos.

Answer 4

Soy un gran fan de solo hacer público lo que explícitamente quiere hacer público. Me gusta el cálido y seguro capullo que mi clase me ofrece.

Answer 5

Los únicos miembros públicos de un tipo deben ser parte de la interfaz pública del tipo en sí. Su objetivo debe ser minimizar la interfaz del tipo a la menor cantidad de miembros y exponer poco a nada de la implementación subyacente.

Answer 6

¡NUNCA haría público mis cuerpos! Período.

Answer 7

Exponga exactamente lo que se necesita para sus clientes previstos y escenarios de uso, y nada más.No consideraría las pruebas unitarias como cliente y realizaría cambios para que el código que no está destinado para el consumo público comience por el público solo por el bien de las pruebas unitarias. Si lo hace, desordenará su API, reducirá la usabilidad de su API y hará que los cambios futuros sean más difíciles y no ideales, ya que ahora puede haber un código de cliente que use lo que se supone que es una API privada.

Verificaría si tiene mejores alternativas. Por ejemplo, puede generar accesos privados en Visual Studio 2005 y 2008 que hagan pública la API no pública de una clase con fines de prueba. Esto puede complicar el código de su unidad de prueba, pero para mí lo más importante es su diseño y la API que está liberando a sus clientes, incluidos usted y su equipo.

En otro aspecto, también mencionaría que las pruebas unitarias le dan una gran oportunidad para ver qué tan bien es su diseño y qué tan fácil es consumir su API desde la perspectiva del cliente. Armado con frustraciones, problemas, etc. durante el desarrollo de la prueba unitaria, usted realiza cambios para mejorar su API y su diseño para que sea más simple, hermoso y utilizable.

Answer 8

Si encuentra que es difícil probar una clase a fondo, entonces la clase puede estar haciendo demasiado. Dividir la clase usando la composición puede hacer que las unidades individuales sean más comprobables.

A veces tiene sentido, otras veces no es así. Solo un pensamiento.