Pregunta

tiene una clase base llamada EventArgs. Derivado de esto son muchas, muchas especializaciones que representan argumentos del evento para un tipo particular de evento. Los consumidores de estos eventos pueden necesitar algunos, muchos o muy pocos de estas clases de argumentos.

Mi pregunta es, ¿podría proporcionar un archivo de cabecera cada tipo (por ejemplo, más de 50 archivos de cabecera para los más variados), habría que tratar de agruparlas en las familias y tienen un 'común 'archivo de cabecera para los que, o te tiro precaución a la ventana y tirarlos a un fichero de cabecera fácil de usar que solo puede ser incluido?

Otro enfoque podría ser tener 50 archivos de cabecera, y luego me podría introducir algunos "familia" de los ficheros de cabecera que incluían los particulares. No está seguro acerca de las convenciones de nombres para este tipo de cosas por lo que es obvio lo que es donde.

Sé que puede que no haya una regla dura y rápida, pero se pregunta qué otros desarrolladores han hecho cuando se encuentran escribiendo muchas clases pequeñas.

Gracias de antemano.

¿Fue útil?

Solución

Me tendría que poner dos clases en las cabeceras separadas en uno de los casos siguientes:

  • son enormes
  • que no están relacionados o poco probable para ser utilizado junto
  • cada uno de ellos presenta sus propias dependencias de cabecera

De lo contrario, no tiene mucho sentido para separarlos. Sé que algunas personas tienen esta "una clase por cabecera" regla, pero no parece razonable en su caso.

¿Qué es para "familias", incluyendo archivos pequeños abundancia, en ciertos sistemas de construcción y sistemas de archivos () esto podría tener impacto en el tiempo de compilación, y en todo caso no veo una razón para hacer esto - por lo general la gente utilizará documentación o IDE para encontrar clases, sin mirar a los nombres de archivo cabeceras. Por lo que sólo haría que para simplificar la inclusión, pero entonces ¿por qué no ponerlos en la misma cabecera.

Otros consejos

Me agruparlas en familias según las clases de usuarios que es probable que desee utilizar juntos. 50+ pequeños ficheros de cabecera parece excesivo en ningún caso.

No se pudo ser todas las variantes plantillas?

he estado en una situación similar en el que yo estaba desarrollando una biblioteca de interfaz gráfica de usuario. Initally todos los componentes (que eran pequeñas clases) compartían el mismo archivo de cabecera y la fuente. Esto funcionó bastante bien. Más tarde trató de ponerlos en archivos separados pero realmente no mejoró nada. Sólo se añadió la carga de tener que gastar mucho tiempo buscando a través de estos archivos.

Aparte de eso, tal vez usted puede dibujar un poco de inspiración de la biblioteca Poco C ++. Esta biblioteca por lo general sigue el modismo una clase por cabecera, pero hay excepciones. Por ejemplo toda la jerarquía de excepción se codifica en un archivo de cabecera y de origen usando un sistema basado macro (ver Exception.h y Exception.cpp ).

si pertenecen al mismo jerarquía de herencia, los puso en el mismo archivo .h. Se le ayuda a decidir el orden correcto para las clases. Uno de los cheques en c menos conocido en tiempo de compilación ++ se basa en el orden correcto de las clases en el archivo .h.

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