2011-05-17 16 views
6

Tengo una clase que tiene algunas funciones que son útiles por sí mismas, que son estáticas. Ahora estas funciones dependen de otras funciones que no son útiles por sí mismas (pero que no interactúan con las variables de los miembros de la clase) pero que también son estáticas, por lo que son privadas. Ahora tengo una clase con muchas funciones no estáticas, y un par de funciones públicas estáticas y algunas funciones privadas estáticas.Función estática que conduce a funciones más estáticas

¿Es esta una buena práctica? (¿Debería hacer de esto una wiki comunitaria?)

+0

no está claro qué quiere decir con "útil/no útil por sí mismo" - ¿puede dar más detalles? – davka

+0

La función estática está formateando algo pesado, así que lo he descompuesto. El usuario/cliente llamará a la función de servicio pesado, que a su vez depende de funciones más pequeñas que no son útiles para el cliente en absoluto y por lo tanto las funciones son privadas (estoy bajo el supuesto de que uno de los usos de declarar una función privada es dar al cliente una fuerte pista de que esta función no está destinada a ser utilizada por nadie, excepto la clase/objeto en sí). – Samaursa

+0

Sé por qué las funciones se hacen privadas o públicas :), es "por su cuenta" lo que me confunde. En realidad, estoy tratando de averiguar si estas funciones deberían pertenecer a la clase, o si pueden ser funciones libres, como sugiere @mkaes. Si no usan miembros estáticos, la única razón por la que pertenecen a la clase es el alcance, lo que significa que son parte conceptual de los servicios de la clase. Bueno, por ej. es el método de fábrica, p.'Documento :: createDoc (Documento :: DocType)' – davka

Respuesta

10

Creo que debería declarar esas funciones como funciones gratuitas. Si no necesitan a los miembros, no debería ser un gran problema.
Quizás debería leer esto article. Me pareció muy útil para mejorar mis diseños de clase.

+0

Sí, la única vez que realmente resulta útil el uso de funciones estáticas en las clases es obtener información sobre la propia clase, la creación Singleton, o algún tipo de clase de fábrica que tiene acceso a miembros/funciones privados de otra clase que crea. Incluso entonces, la fábrica debe ser una instancia para que pueda contener punteros o información sobre sus objetos creados –

+0

Gracias por el enlace. Leeré ese artículo tan pronto como encuentre el tiempo. Aunque tengo una pregunta. Teniendo en cuenta que tengo algunas funciones que no son de ninguna utilidad para el usuario (y por lo tanto son privadas), ¿cómo se lo sugiero al usuario con una función gratuita? – Samaursa

+0

@Samaursa: Póngalos en un espacio de nombres 'detail' si los necesita a través de múltiples' .cpp' o simplemente los puso en el '.cpp' donde se utilizan (en un espacio de nombres sin nombre) . – Xeo

4

Eso suena bien, y funcionaría bien. Sin embargo, hay algunas cosas que considerar.

Es posible que las funciones estáticas privadas sean aún más privadas. Si acaba de colocarlos en el archivo .cpp como funciones gratuitas (no en una clase, pero idealmente en un "espacio de nombres sin nombre"), entonces no aparecerían en el archivo .h. Esto sería ventajoso porque otro archivo .cpp que utiliza su clase no vería estas variables estáticas privadas. Eso haría que el tiempo de compilación sea más rápido. Además, le dejaría libre para alterar las funciones en el archivo .cpp, y si realizó algún cambio, no sería necesario volver a compilar todos los archivos que utilizan el archivo .h ya que no tendría que cambiar el archivo. .h archivo para cambiar estas funciones.

En segundo lugar, a veces las funciones estáticas pueden hacer que la escritura de las pruebas unitarias sea más complicada. Si tiene una clase X que utiliza estas funciones estáticas, es complicado aislar la clase X de las funciones estáticas si desea probar la clase X. Si, en cambio, utilizó métodos no estáticos y definió una clase de interfaz que la clase que está escribiendo deriva de, podría usar más fácilmente las técnicas de 'inversión de control' e 'inyección de dependencia' para escribir pruebas de unidad para sus clases. No explicaré esas técnicas aquí, ya que hay muchas descripciones buenas que ya flotan en Internet.

+0

+1 Buenos puntos sobre el uso de espacios de nombres sin nombre en el archivo .cpp y sobre la prueba unitaria. – Joseph

0

Hazlo simple. La función static que no tiene nada que ver con la clase se puede encapsular en un class interno o en un nuevo namepsace. por ejemplo

struct A 
{ 
    struct Util // can also be put outside in a namespace for others to use 
    { 
    static void Independent() { } 
    }; 
    static void dependent(); 
}; 
+0

"Keep it simple" seguido de una solución demasiado complicada. –

+0

@Tomalak, LOL .. de todos modos, eso era para una mejor organización del código. – iammilind

0

Me gustaría ver las "funciones no estáticos muchos", así como, probablemente, se puede dividir la clase en algunas entidades más pequeñas relacionadas por herencia o, idealmente, ser más independiente y podrían ser llevados a la forma inicial por composición. En general, la palabra "muchos" no es un signo de buen diseño.

Cuestiones relacionadas