2010-01-18 15 views
6

Digamos que quiero algunas funciones para tratar con algún archivo, y estaba considerando 2 opciones.¿Debo usar una clase de funciones o un espacio de nombres de funciones?

1) Crear una clase como SavedDataHandler que un usuario podría utilizar como esto ....

// Note that SavedDataHandler has no members. It just has functions that operate on a 
// resource (the file) 
SavedDataHandler gameSave; 
gameSave.SaveData(arg1, arg2); // to save data 
gameSave.DeleteSave(); // Delete the save 
... 

2) Crear un espacio de nombres de funciones

namespace SavedDataHandler { 
    SaveData(...) { ... } 
    DeleteSave(...) { ... } 
    ... 
} 

que un usuario llame como

SavedDataHandler::SaveData(arg1, arg 2); 
SavedDataHandler::DeleteSave(); 

¿Cuál sería preferido?

P.S. Pensé en esto cuando estaba pensando en la recomendación de Scott Meyer de preferir las funciones no miembro de no amigos a las funciones de miembro. Me he encontrado con decisiones en las que tengo una función (por lo general, una función de miembro privado para ayudar a la clase a hacer cosas), que fácilmente podría convertirse en un no miembro, ya que no funciona en clases privadas.

Sin embargo, la función solo la usa esa clase. Por supuesto, el programa podría evolucionar hasta el punto en que otra clase lo necesite, pero me resulta difícil encontrar un lugar para estas funciones que no son miembros. Es fácil cuando tienes muchas funciones con un propósito general, pero considero que las funciones individuales que no son miembros son difíciles de organizar en un lugar específico, y considero que dejarlo como miembro lo mantiene limpio. ¿Algún consejo sobre este tema?

Respuesta

4

que tienden a la siguiente distribución simplificada:

  • si es para uso exclusivo de una clase y es probable que siga así, lo puso en el archivo de implementación en un espacio de nombres en el anonimato.
  • si es útil para más de una clase y no necesita acceder al estado interno de una clase, póngalo en un espacio de nombres.
  • si necesita acceso al estado interno de la clase, hágalo miembro por supuesto.

Pero las opiniones difieren y, al final, probablemente las pautas de su empleador sean las definitivas.

Editar:

... Por supuesto que no es que simple, pero como usted ha mencionado Scott Meyers already covered los detalles.

En cuanto al problema de organización:
Si pones funciones auxiliares en los espacios de nombres anónimos, que ya están desacoplados en su mayoría de la clase - si luego decide volver a usarlos, no debe ser demasiado duro para sacarlos en un espacio de nombres común.
En este punto, también debería tener una mejor visión de la organización que se ajusta, que a veces puede ser difícil por adelantado.

+0

Más o menos la misma heurística que uso :) –

+0

¡Gracias por vincularme al artículo de Scott Meyers sobre ddj! – Pete

0

Tendría sentido tener el método save de la clase que contiene los datos del juego directamente, pasando objetos auxiliares que representan los medios en los que se guardan los datos, y que el método delete esté en la clase de medios propiamente dicha.

+0

Esto es lo que Scott Meyer argumenta en contra. Ver http://www.ddj.com/cpp/184401197 –

1

Mi respuesta subjetiva es: use un espacio de nombres en una clase que contenga métodos estáticos.

Mi razonamiento para esto es que con solo mirar la declaración sabrá el propósito de este bloque de código.

Si se trata de una clase, no hay nada que impida que tenga métodos de instancia. Si es un espacio de nombres, entonces sabes que todas las funciones son autónomas.

Estos conceptos me llaman la atención cuando aprendo C#. En C# no puede tener funciones independientes. Sin embargo, puede tener clases estáticas:

internal static class SavedDataHandler 
{ 
    // Because this is a static class, the compiler will not let you create an instance method 

    internal static void ThisIsAStaticFunction() // This is fine 
    { 
    } 

    internal void ThisIsAnInstanceFunction() // Compiler error! 
    { 
    } 
} 

como C++ no tiene el concepto de clases estáticas, espacios de nombres sería el camino a seguir.

0

Si debo responder la pregunta en sí, sería: No importa. Se podría decir que la diferencia entre un espacio de nombres de funciones y una clase con funciones estáticas en este caso es solo sintáctica.

Sin embargo, parece que está intentando modelar un objeto "SavedGame". ¿Hay alguna razón por la cual estas funciones deberían tener un controlador diferente sin estado?

0

Parece que esta pregunta se debe a un diseño poco saludable en otras partes del programa. Me gustaría ver el diseño de estas cosas arg1 y arg2 que está pasando al manejador, es probable que estén donde falta la abstracción.

Cuestiones relacionadas