2012-10-04 30 views
12

Al escribir un método auxiliar para una clase en C++, ¿debería declararse como un método privado en la definición de la clase en el archivo de encabezado (.h)? Por ejemplo:¿Debe una función auxiliar ir en el encabezado o en el archivo de implementación?

/*Foo.h*/ 
class Foo { 

    public: 
     int bar(); 

    private: 
     int helper(); 
}; 
... 
/*Foo.cpp*/ 
... 
int foo::bar() { 
    int something = this->helper(); 
} 

int foo::helper() { 
    ... 
} 

O, alternativamente, es mejor no la declara como un miembro privado de la clase, y en su lugar sólo hacen que sea una función independiente en la ejecución?

/*Foo.h*/ 
class Foo { 
    public: 
     int bar(); 
}; 
... 
/*Foo.cpp*/ 
... 
int Foo::bar() { 
    int something = helper(); 
    ... 
} 

int helper() { 
    ... 
} 

Respuesta

18

Una función independiente en el archivo de aplicación mejora la encapsulación: necesita ninguna declaración en la cabecera, por lo que no recompilación del código de cliente cuando cambia su firma por cualquier razón. Para mí, esa es una buena razón para preferir esta opción siempre que sea posible. (Asegúrese de ponerlo en el espacio de nombres en el anonimato para evitar enfrentamientos identificador en el momento del enlace.)

Sin embargo, un método private tiene acceso a una instancia de clase y sus partes íntimas a través de el puntero this. Si necesita dicho acceso, entonces debe ser un método o un friend. En ambos casos, será visible en la definición de clase (archivo de encabezado), y los métodos son simplemente más convenientes que los amigos.

+1

Para expandir su segundo párrafo: [prefiere las funciones de no miembro que no sean amigos] (http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197). Si una función no necesita acceso privado, no le dé acceso privado. –

+0

@sftrabbit: gracias. Agudé el segundo párrafo un poco. –

1

Mi posición es que el encabezado contiene la menor cantidad posible de anuncios al tiempo que se logran las propiedades deseadas de diseño y diseño. Si hay una opción, entra en la fuente. Sin embargo, algunos detalles internos necesitan acceso a demasiados detalles internos de una clase para que sea viable entrar en la implementación.

4

Si su función auxiliar tiene sentido para ser un método del objeto, casi siempre preferiría hacer una función miembro por lo que hay un puntero implícito this, en lugar de pasar un Foo * a la función auxiliar.

Si la función auxiliar no necesita ser un método del objeto (es decir, no necesita acceder a los miembros de datos u otras funciones miembro), entonces conviértalo en una función independiente (static o anónima espacio de nombres, preferiblemente).

2

Esto es un poco subjetivo, creo.

En mi opinión, depende de si tiene algo que ver con los miembros de la clase y/o si espera que las clases amigas lo usen (o las clases derivadas en el caso del acceso protected).

Si la función no funciona en ningún miembro, y nadie más está interesado en ella, debe mantenerla en el archivo de implementación como una función estática. Además, si se trata de una operación que debe ser rápida, puede aprovechar la oportunidad para hacerlo inline.

Por el contrario, si la función funciona en la clase o puede tener usos adicionales en las clases derivadas o relacionadas, hágalo miembro.

Cuestiones relacionadas