printable - name tags design
¿Cuándo deberían los métodos ser privados? (12)
Hay muchas ocasiones en las que no estoy seguro de si un método en particular debe ser privado o no. Por ejemplo, estoy construyendo una clase en este momento, que es responsable de generar un informe. Esta clase tiene un método buildReport y varios métodos que recopilan los datos necesarios para buildReport.
// single public method
// uses a set of helper methods
public buildReport()
// helper methods
private avgSurveyTime()
private fetchVendors()
private fetchSendCounts()
private ...
Estoy debatiendo si debo hacer públicos estos métodos de ayuda. El único método que realmente planeo llamar al aire libre en este momento es buildReport() . Sin embargo, podría ser útil obtener solo una lista de los proveedores con fetchVendors() etc.
Veo dos escuelas de pensamiento sobre esto: siempre puedes exponer lo menos posible. (En cuyo caso, muchas de mis clases solo tendrían un método público) O puede exponer todo lo que pueda que pueda ser útil para el usuario de la clase.
¿Existe una buena regla de oro para decidir cuándo los métodos deben hacerse públicos / privados?
Debes exponer al mundo exterior solo lo que el mundo exterior realmente necesita. A menudo es mejor agregar funcionalidad para los consumidores de la clase cuando es necesaria , en lugar de al principio. En estos días, la sabiduría es evitar la preingeniería . ( ver YAGNI )
Ciertamente, puede ser aceptable tener métodos públicos que también sean utilizados por otras funcionalidades dentro de la clase. Sin embargo, esto debería considerarse un mal olor menor . Podría ser una indicación de que su clase está tratando de hacer demasiadas cosas.
Mi suposición es dejar tus clases como están. Entonces, cuando el mundo exterior necesite estos otros métodos más pequeños, considere si debe separar sus clases. Si el propósito de cada una de estas clases es generar un informe, entonces no debe exponer estos métodos de este objeto. En cambio, ponga métodos "más pequeños" en una clase auxiliar común. De esta manera, están disponibles para el mundo exterior sin cambiar fundamentalmente la naturaleza de las clases de informes existentes. En breve:
No lo haga solo porque cree que podría ser útil más adelante . Si / Cuando se necesita la funcionalidad adicional, reconsidere su diseño general para adaptarse a los nuevos requisitos.
Estoy trabajando en un sistema compuesto principalmente de dos cosas: importar datos de diversas fuentes y generar informes. El problema es que todo fue diseñado por alguien que carecía de las habilidades básicas de diseño de OO. En la misma ''clase'' tendrían métodos ''privados'' para leer datos de una base de datos, llamando a métodos ''privados'' para validar dichos datos, que también está siendo llamado por otra función ''privada'' de 500 líneas duplicada más o menos en el toda la aplicación que simplemente formatea dichos datos.
Debe alejarse privado avgSurveyTime () private fetchVendors () privado fetchSendCounts () de la clase real que maneja el diseño de página.
La única regla que sigo es hacer público lo menos posible.
Míralo de esta manera. Siempre puede hacer público algo más adelante; no romperá ningún código existente. Tratar de hacer algo privado que fuera público bien podría terminar rompiendo una gran cantidad de código existente.
Si alguien quiere más funcionalidad de su clase, entonces pueden hacer la solicitud y puede exponer lo que necesitan. Lo más probable es que quieran algo que sea sutilmente diferente de lo que ya tienes de todos modos, así que necesitarás una nueva interfaz.
La regla es que se debe proporcionar un método a menos que sea necesario. Una de las principales razones para esto es que en una versión futura de una API, etc., siempre puede hacer pública una función privada, pero casi nunca puede hacer que una función pública previa sea privada sin romper el código existente.
Los métodos públicos y privados son bestias muy diferentes. Tenga cuidado antes de hacer un método público.
- Los métodos públicos deben validar todos sus parámetros.
- Deben estar debidamente documentados, incluidas las excepciones que puedan arrojar.
- Todos los casos de borde deben analizarse y delt con (en el código o en la documentación).
- Cualquier requisito que implique el orden en que se llaman los métodos públicos debe documentarse o, preferiblemente, eliminarse.
- Los requisitos del estado del objeto también se deben documentar y validar.
- Los métodos públicos no deben cambiar su firma o comportamiento de ninguna manera que pueda romper una aplicación al pasar de una versión a la siguiente.
- Los métodos públicos pueden necesitar ser diseñados con requisitos de clasificación. (Como las restricciones CLS de .Net).
Los métodos privados no tienen ninguna de estas limitaciones.
Si la clase es para uso interno dentro de su organización, es decir, no está distribuyendo esto como una biblioteca de uso general, acepto sinceramente que debe hacer todo lo posible, tanto privado como protegido. Si más tarde descubres que alguna otra clase necesita acceder a una función privada, está bien, en ese punto cámbiala a pública. Esto no es difícil de hacer.
Mi única advertencia sería si esto es algo que está "publicando", donde otros que no tengan una línea directa para hacer cambios lo usarán. Entonces necesitas pensar cuidadosamente una API completa.
Pero en su defecto, solo escriba el código que necesita. No escriba funciones que cree que podría usar algún día.
Si no es necesario fuera de la clase, está en ese mismo momento, hazlo en privado. Si más tarde es así, puede hacerlo protegido o público según sea necesario.
En caso de duda, hazlo en privado.
Siempre sigo esto: " Diseña para mañana, codifica para hoy " .
Si hoy solo necesita un método público, guarde solo un método público.
Todo lo que no está incluido en la interfaz de la clase debe (debe ser) realmente privado. Si no está seguro de cuál es la interfaz de la clase (es decir, no está http://www.artima.com/lejava/articles/designprinciples.html>programando las interfaces o esas interfaces aún no están completamente definidas, comience con todo privado y hacer las cosas públicas, protegidas, privadas como paquetes, etc. según sea necesario.
¡Pero piensa cuidadosamente! Una vez que algo es accesible para otro código, existe una dependencia entre ese código y esta clase y la refactorización está restringida. Regla general: Exponga solo los métodos que definen la abstracción, no cómo se implementan.
Una técnica de guía útil a seguir es escribir una interfaz para su clase antes de comenzar la implementación. Luego, cuando implemente, dígale que un método que no está en la interfaz debe ser privado o no pertenecer a esa clase.
Si no sabía que un método necesitaba estar allí cuando estaba diseñando el contrato de la clase, probablemente no debería formar parte de su interfaz pública.
reglas simples:
Si no está buscando exponerlo fuera de la clase que lo está utilizando, hágalo PRIVADO .
Si está buscando exponerlo dentro del mismo conjunto a otras clases pero no fuera del ensamblaje, hágalo INTERNO (C #) / Amigo (VB.NET).
Si busca exponer la funcionalidad fuera del ensamblaje a todos, hágalo PÚBLICO
En general, debe exponer lo menos posible y hacer todo lo privado que sea posible.
Si comete un error y esconde algo que debería estar exponiendo, no hay problema, solo hágalo público. Sin embargo, si hace algo público y luego decide que debe ser privado, entonces puede tener problemas porque ahora el método público puede ser utilizado por muchas otras clases.
Usted es libre de cambiar la implementación de sus métodos privados sin ningún efecto externo. Si tiene todas las clases públicas, eso puede no ser posible, porque esos métodos podrían ser utilizados por algunas personas fuera de sus clases.