Pregunta

Cuando se crea una estructura de herencia C ++, tiene que definir funciones miembro exactamente la misma en múltiples lugares:

Si B es una clase base abstracta, y D, E y F se hereda de B, que podría tener este aspecto:

class B
{
   virtual func A( ... params ) = 0;
};

class D : public B
{
   func A( ... params );
};

/* ... etc... similar implementations for E and F */

Por lo tanto, es evidente que existe cierta duplicación aquí. Si la interfaz de A a B es grande, es posible que tenga muchos lugares que cambiar si las necesidades de conexión a cambio.

Un compañero de trabajo sugirió algún truco con un incrustados #includes creados artesanalmente-, Ala:

class D: public B
{
   #include "B_Interface.h"  // B_Interface.h is a specially crafted .h file
}

Esto parece un poco kludgy? ¿Lo es? ¿Hay una mejor solución para evitar la doble mantenimiento?

Además, puede que la solución aquí es realmente mejores herramientas para apoyar la lengua, como Visual Assist X?

Edit:. Supongamos que las clases derivadas debe tener implementaciones únicas

¿Fue útil?

Solución

En realidad, el mayor problema con el cambio de una interfaz por lo general es todo el código que usos , no el código que implementa. Si es fácil cambiarlo por el implementador, que probablemente haría la vida más difícil para los usuarios.

Otros consejos

Esto es doloroso para cambiar una interfaz ampliamente utilizado no es un error; se trata de una función.

  

Además, puede que la solución aquí es realmente mejores herramientas para apoyar la lengua, como Visual Assist X?

Exactamente. Cambio de firmas de los métodos es una característica clave de herramientas de refactorización.

Si usted tiene que poner en práctica una y otra vez con un poco de comportamiento por defecto entonces tal vez sólo debe ser virtual y no virtual pura.

En lugar de utilizar el preprocesador de otra manera que no debe utilizarse Me gustaría probar mi editor (o IDE, si eso es lo que te gusta.)

scroll top