¿Qué patrones usa para desacoplar interfaces e implementación en C++?

Question

Un problema en grandes proyectos de C++ puede ser tiempos de compilación. Hay una clase alta en su árbol de dependencias en la que tendría que trabajar, pero generalmente evita hacerlo porque cada compilación lleva mucho tiempo. No necesariamente quiere cambiar su interfaz pública, pero tal vez quiera cambiar sus miembros privados (agregue una variable de caché, extraiga un método privado, ...). El problema al que se enfrenta es que en C++, incluso los miembros privados se declaran en el archivo de encabezado público, por lo que su sistema de compilación necesita volver a compilar todo.

¿Qué haces en esta situación?

He esbozado dos soluciones que conozco, pero ambas tienen sus desventajas, y tal vez hay una mejor en la que todavía no he pensado.

Answer 1

El patrón pimpl:

En el archivo de cabecera, sólo se declaran los métodos públicos y privados un puntero (el pimpl y agujas, o delegado) a una clase de implementación hacia adelante declarado.

En su fuente, declare la clase de implementación, reenvíe cada método público de su clase pública al delegado y construya una instancia de su clase pimpl en cada constructor de su clase pública.

Plus:

• Le permite cambiar la implementación de su clase sin tener que recompilar todo.
• La herencia funciona bien, solo la sintaxis se vuelve un poco diferente.

Menos:

• Montones y montones de cuerpos de métodos estúpidos a escribir para hacer la delegación.
• Es un poco incómodo de depurar ya que tiene un montón de delegados para pasar.
• Puntero adicional en su clase base, lo que podría ser un problema si tiene muchos objetos pequeños.

Answer 2

de la herencia:

En su cabecera, declaran los métodos públicos como los métodos virtuales puros y una fábrica.

En su fuente, obtenga una clase de implementación de su interfaz e impleméntela. En la implementación de la fábrica devuelve una instancia de la implementación.

Plus:

• Le permite cambiar la implementación de su clase sin tener que recompilar todo.
• Fácil y infalible de implementar.

Menos:

• realmente difícil de definir un (público) instancia derivada de la clase base pública que debe heredar algunos de los métodos de la aplicación (privada) de la base pública.

Answer 3

Puede usar una declaración directa para la clase A a la que se hace referencia mediante puntero en otra clase B. Luego puede incluir el archivo de encabezado A de clase en el archivo de implementación de la clase B en lugar de su archivo de encabezado. De esta forma, los cambios que realice en la clase A no afectarán a los archivos fuente que incluyen el archivo de encabezado de la clase B. Cualquier clase que quiera acceder a los miembros de la clase A deberá incluir el archivo de encabezado de la clase A.

Answer 4

John Lakos 'Large Scale C++ Software Design es un excelente libro que aborda los desafíos involucrados en la construcción de grandes proyectos de C++. Los problemas y las soluciones están todos basados ​​en la realidad, y ciertamente el problema anterior se discute en detalle. Muy recomendable.

Answer 5

La refactoreo y uso del idioma pimpl/handle-body, el uso de interfaces virtuales puras para ocultar los detalles de implementación parece ser la respuesta popular. Uno debe considerar el tiempo de compilación y la productividad del desarrollador al diseñar sistemas grandes. ¿Pero qué ocurre si está trabajando en un gran sistema C++ existente sin cobertura de prueba unitaria? La refactorización generalmente está fuera de discusión.

Lo que suelo hacer cuando no quiero que el compilador compile el mundo después de haber tocado algunos archivos de encabezado comunes es tener un makefile/script para compilar solo los archivos que sé necesitan recompilar. Por ejemplo, si estoy agregando una función privada no virtual a una clase, solo el archivo cpp de la clase necesita ser recompilado, incluso cuando su archivo de encabezado está incluido en un centenar de otros archivos. Antes de irme por el día, comienzo una construcción limpia para reconstruir el mundo.

Answer 6

Ninguno.

veo el punto en el uso de uno, pero creo que los siguientes argumentos mitigar ese punto en muchos escenarios:

1. La claridad es lo primero. Si se pone en peligro la claridad del tiempo de ejecución , la velocidad debe considerarse dos veces, ¿qué acerca de la claridad comprometedora para tiempo de compilación velocidad?
2. Los miembros privados no deberían cambiar tan a menudo.
3. Por lo general, no toma que largo para reconstruir todo.
4. Herramientas más rápidas vendrán en el futuro, por lo que el problema de compilación de velocidad se mitigará automáticamente. Tu código no se aclarará automáticamente.
5. Debe reconstruir con frecuencia de todos modos.
6. ¿Has probado Incredibuild?

Por supuesto que al final esta es una decisión económica. Si el peso de "3" es importante en su proyecto y por alguna razón "6" no puede aplicarse, entonces continúe: ganará más usando estas plantillas de lo que pierde.