Pregunta Nombrar clases: ¿cómo evitar llamar a todo un " Manager"? [cerrado]


Hace mucho tiempo, leí un artículo (creo que una entrada de blog) que me puso en el camino "correcto" para nombrar objetos: Sé muy escrupuloso a la hora de nombrar cosas en tu programa.

Por ejemplo, si mi aplicación fuera (como una aplicación comercial típica) manejando usuarios, empresas y direcciones, tendría una User, un Company y un Address clase de dominio, y probablemente en algún lugar UserManager, un CompanyManager y un AddressManager aparecería que maneja esas cosas.

Entonces puedes decir que esos UserManager, CompanyManager y AddressManager ¿hacer? No, porque Manager es un término muy muy genérico que se ajusta a todo lo que puede hacer con sus objetos de dominio.

El artículo que leí recomienda usar nombres muy específicos. Si era una aplicación C ++ y el UserManagerEl trabajo consistía en asignar y liberar a los usuarios del heap que no administraría a los usuarios, sino que protegería su nacimiento y muerte. Hmm, tal vez podríamos llamar esto UserShepherd.

O tal vez el UserManagerEl trabajo es examinar los datos de cada objeto de usuario y firmar los datos criptográficamente. Entonces tendríamos un UserRecordsClerk.

Ahora que esta idea me quedó grabada, trato de aplicarla. Y encuentra esta simple idea increíblemente difícil.

Puedo describir lo que hacen las clases y (siempre que no me deslice en la codificación rápida y sucia) las clases que escribo hacen exactamente uno cosa. Lo que echo de menos pasar de esa descripción a los nombres es un tipo de catálogo de nombres, un vocabulario que correlaciona los conceptos con los nombres.

En última instancia, me gustaría tener algo así como un catálogo de patrones en mi mente (con frecuencia los patrones de diseño proporcionan fácilmente los nombres de los objetos, por ejemplo, un fábrica)

  • Fábrica: crea otros objetos (nombres tomados del patrón de diseño)
  • Shepherd - Un pastor maneja la vida de los objetos, su creación y cierre
  • Sincronizador: copia datos entre dos o más objetos (o jerarquías de objetos)
  • Niñera: ayuda a los objetos a alcanzar el estado "utilizable" después de la creación, por ejemplo, mediante el cableado a otros objetos

  • etcétera etcétera.

Entonces, ¿cómo manejas ese problema? ¿Tiene un vocabulario fijo, inventa nuevos nombres sobre la marcha o considera nombrar cosas que no son tan importantes o incorrectas?

P.S .: También me interesan los enlaces a artículos y blogs que discuten el tema. Para empezar, aquí está el artículo original que me hizo pensar al respecto: Nombrar clases de Java sin un 'Administrador'


Actualización: Resumen de respuestas

Aquí hay un pequeño resumen de lo que aprendí de esta pregunta mientras tanto.

  • Intenta no crear nuevas metáforas (Niñera)
  • Echa un vistazo a lo que hacen otros frameworks

Otros artículos / libros sobre este tema:

Y una lista actual de prefijos / sufijos de nombre que recopilé (¡subjetivamente!) De las respuestas:

  • Coordinador
  • Constructor
  • Escritor
  • Lector
  • Entrenador de animales
  • Envase
  • Protocolo
  • Objetivo
  • Convertidor
  • Controlador
  • Ver
  • Fábrica
  • Entidad
  • Cangilón

Y un buen consejo para el camino:

No digas parálisis. Sí, los nombres son muy importantes pero no son lo suficientemente importantes como para perder grandes cantidades de tiempo. Si no puedes encontrar un buen nombre en 10 minutos, sigue adelante.


934
2017-12-08 13:26


origen


Respuestas:


Le pregunté a un pregunta similar, pero cuando es posible trato de copiar los nombres que ya están en .NET Framework, y busco ideas en los frameworks de Java y Android.

Parece Helper, Managery Util son los sustantivos inevitables que adjunta para coordinar clases que no contienen ningún estado y que generalmente son de procedimiento y estáticos. Una alternativa es Coordinator.

Usted podría obtener un enjuiciamiento especialmente morado con los nombres e ir por cosas como Minder, Overseer, Supervisor, Administratory Master, pero como he dicho, prefiero mantenerlo como los nombres de frameworks a los que estás acostumbrado.

Algunos otros sufijos comunes (si ese es el término correcto) que también encuentras en .NET framework son:

  • Builder
  • Writer
  • Reader
  • Handler
  • Container

153
2017-12-08 12:59



Puedes echar un vistazo a source-code-wordle.de, He analizado allí los sufijos utilizados con mayor frecuencia de los nombres de clase del .NET framework y algunas otras bibliotecas.

Los mejores 20 son:

  • atributo
  • tipo
  • ayudante
  • colección
  • convertidor
  • entrenador de animales
  • información
  • proveedor
  • excepción
  • Servicio
  • elemento
  • gerente
  • nodo
  • opción
  • fábrica
  • contexto
  • ít
  • diseñador
  • base
  • editor

88
2017-12-08 13:13



Estoy a favor de los buenos nombres, y a menudo escribo sobre la importancia de tener mucho cuidado al elegir nombres para las cosas. Por esta misma razón, desconfío de las metáforas al nombrar las cosas. En la pregunta original, "fábrica" ​​y "sincronizador" parecen buenos nombres para lo que parecen significar. Sin embargo, "pastor" y "niñera" no lo son, porque se basan en metáforas. Una clase en tu código no puede ser literalmente una niñera; lo llamas una niñera porque se ocupa de otras cosas como una niñera de la vida real cuida de bebés o niños. Eso está bien en el habla informal, pero no está bien (en mi opinión) para nombrar las clases en el código que tendrá que ser mantenido por quién sabe quién sabe cuándo.

¿Por qué? Porque las metáforas dependen de la cultura y, a menudo, también dependen de cada individuo. Para usted, nombrar a una "niñera" de la clase puede ser muy claro, pero tal vez no sea tan claro para otra persona. No debemos confiar en eso, a menos que esté escribiendo código que sea solo para uso personal.

En cualquier caso, la convención puede hacer o deshacer una metáfora. El uso de "fábrica" ​​en sí se basa en una metáfora, pero que ha existido desde hace bastante tiempo y actualmente es bastante conocida en el mundo de la programación, por lo que diría que es seguro de usar. Sin embargo, "niñera" y "pastor" son inaceptables.


50
2017-12-08 13:18



Podríamos prescindir de cualquier xxxFactory, xxxManager o xxxRepository clases si modelamos el mundo real correctamente:

Universe.Instance.Galaxies["Milky Way"].SolarSystems["Sol"]
        .Planets["Earth"].Inhabitants.OfType<Human>().WorkingFor["Initech, USA"]
        .OfType<User>().CreateNew("John Doe");

;-)


39
2017-12-08 13:02



Suena como una pendiente resbaladiza a algo que se publicaría en thedailywtf.com, "ManagerOfPeopleWhoHaveMortgages", etc.

Supongo que es correcto que una clase de Manager monolítica no sea un buen diseño, pero usar 'Manager' no es malo. En lugar de UserManager podemos dividirlo en UserAccountManager, UserProfileManager, UserSecurityManager, etc.

'Manager' es una buena palabra porque muestra claramente que una clase no representa una 'cosa' del mundo real. 'AccountsClerk': ¿cómo se supone que debo decir si esa es una clase que maneja los datos del usuario, o representa a alguien que es un empleado de cuentas para su trabajo?


31
2017-12-08 13:12



Como le interesan los artículos en esta área, podría interesarle el artículo de opinión de Steve Yegge "Ejecución en el reino de los sustantivos":

http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html


19



Cuando me encuentro pensando en usar Manager o Helper en un nombre de clase, lo considero un olor de código que significa que todavía no he encontrado la abstracción correcta y / o estoy violando el principio de responsabilidad única, por lo tanto, refactorizar y poner más esfuerzo en el diseño a menudo hace que nombrar sea mucho más fácil.

Pero incluso las clases bien diseñadas no se nombran (siempre), y sus elecciones dependen en parte de si está creando clases de modelo de negocio o clases de infraestructura técnica.

Las clases de modelo de negocio pueden ser difíciles, porque son diferentes para cada dominio. Hay algunos términos que uso mucho, como Policy para las clases de estrategia dentro de un dominio (p. LateRentalPolicy), pero estos generalmente fluyen de tratar de crear un "lenguaje ubicuo"que puede compartir con usuarios empresariales, diseñando y nombrando clases para que modelen ideas, objetos, acciones y eventos del mundo real.

Las clases de infraestructura técnica son un poco más fáciles porque describen dominios que conocemos muy bien. Prefiero incorporar nombres de patrones de diseño en los nombres de las clases, como InsertUserCommand,  CustomerRepository, o SapAdapter. Comprendo la preocupación por comunicar la implementación en lugar de la intención, pero los patrones de diseño combinan estos dos aspectos del diseño de clase, al menos cuando se trata de infraestructura, donde se desea la implementación. diseño ser transparente incluso mientras oculta los detalles.


16