Escribo un motor XNA y estoy almacenando todos los modelos en un List. Para poder usar esto en todo el motor, hice esto como public static List<Model> para poder acceder a él desde cualquier clase nueva que desarrolle. Ciertamente hace que obtener la lista de modelos sea realmente fácil de obtener, ¿pero es este el uso correcto? ¿O sería mejor pasar una variable en una declaración de método?¿Estoy usando estática de la manera correcta?
En OOP, generalmente es aconsejable evitar el uso de métodos y propiedades estáticos, a menos que tenga una muy buena razón para hacerlo. Una de las razones es que, en el futuro, es posible que desee tener dos o más instancias de esta lista por algún motivo, y luego tendrá que realizar llamadas estáticas.
Los métodos y propiedades estáticos son demasiado rígidos. Como Stevey afirma que:
Los métodos estáticos son tan flexibles como granito. Cada vez que usa uno, , está generando parte de su programa en concreto . Solo asegúrese de no hacer con el pie atascado allí como lo está viendo endurecer. Algún día se sorprenderá de que, por Gosh, que realmente necesita otra aplicación de esa clase Dang PrintSpooler y que debería haber sido una interfaz, una fábrica , y un conjunto de clases de implementación . D'oh!
Sugeriría implementar un objeto Singleon que encapsule la lista modelo.
Eche un vistazo a MSDN singleton implementation.
Los singleton tienen sus propias desventajas, y en realidad no son muy diferentes de los objetos que tienen métodos estáticos. Aquí hay una publicación al respecto: http://sites.google.com/site/steveyegge2/singleton-considered-stupid En general, es mejor simplemente crear un objeto y pasarlo como parámetro a quien necesite usarlo. –
Esto es una cuestión de equilibrio y compensaciones.
Por supuesto, los puristas de OOP dirán que eviten a toda costa estas variables globales, ya que rompe la compartimentación de código al introducir algo que sale de la caja para cualquier módulo, y así hace que sea difícil de mantener, cambiar, depurar, etc.
Sin embargo, mi experiencia personal ha sido que debe evitarse solo si usted es parte de un equipo de soluciones empresariales muy grande, manteniendo una gran aplicación de clase empresarial.
Para otros casos, encapsular datos accesibles globalmente en un objeto "global" (o un objeto estático, lo mismo) simplifica la codificación OOP en gran medida.
Puede obtener el término medio escribiendo una función global GetModels() que devuelve la lista de modelos. O use DI para inyectar automáticamente la lista de modelos.
Los proyectos pequeños pueden crecer más tarde. E incluso los proyectos más pequeños deben ser verificables. La estática es enemiga de las pruebas unitarias. –
@ František Žiačik, buen punto! +1 Es por eso que menciono que puede necesitar tener una función GetModels() para que pueda inyectar un dummy en pruebas unitarias ... –
@ František Žiačik, sin embargo, en el desarrollo de juegos, generalmente hay una gran cantidad de datos globales (por ejemplo, datos de la placa, datos del terreno, datos de los jugadores, etc.) para sincronizar entre secuencias de código. En realidad, los datos globales generalmente superan con creces los datos no globales. Entonces debe haber alguna forma de equilibrio. –
Evitaría usar estática tanto como sea posible, con el tiempo terminarás con spaghetti code.
Si lo pasa en el constructor está eliminando una dependencia innecesaria, low coupling is good. Cuantas menos dependencias haya, mejor.
Para el desarrollo de juegos defiendo "Hacer lo más simple que podría funcionar". Eso incluye el uso de variables globales (public static en C#), si esa es una solución fácil. Siempre puedes convertirlo en algo más formal más tarde. La herramienta "encontrar todas las referencias" en Visual Studio hace que esto sea realmente fácil.
Dicho esto, hay muy pocos casos en los que una variable global es en realidad la forma "correcta" de hacer algo. Por lo tanto, si va a usarlo, debe ser al tanto de y para comprender la solución correcta. Así que puede hacer la mejor compensación entre "ser flojo" y "escribir un buen código".
Si va a hacer algo global, debe comprender por completo por qué lo está haciendo.
En este caso particular, parece que intentas tratar de obtener contenido. Tenga en cuenta que ContentManager devolverá automáticamente el mismo mismo objeto de contenido si lo solicita varias veces. Por lo tanto, en lugar de cargar modelos en una lista global, considere la posibilidad de hacer que su clase Game incorporada ContentManager esté disponible a través de una propiedad public static en su clase Game.
O, mejor aún, hay un método que prefiero, que creo que es un poco mejor: I explain it in the answer to another question. Básicamente, usted hace las referencias de contenido private static en las clases que las usan y pasa el ConentManager en las funciones public static LoadContent. Esto divide el uso de clases estáticas a individuales, en lugar de utilizar un global al que se accede desde todo el programa (lo cual sería difícil de resolver más adelante). También maneja correctamente el contenido de carga en , hora correcta.
¿Está utilizando algún tipo de enhebrado? Si es así, entonces realmente quieres evitar una lista estática. – Marthin
@Marthin: no se está utilizando subprocesos. –
Luego, desde mi experiencia, creo que podría continuar con su lista estática siempre que sepa que es un proyecto bastante pequeño. Sin embargo, si crees que esto podría crecer, te sugiero ir a una fábrica. Por supuesto, las fábricas no son óptimas para todos estos tipos de implementaciones, pero para mí, hacen que la implantación sea un poco más fácil y más práctica. Finalmente un consejo: Lee Java efectivo por Joshua Bloch. Las mejores prácticas para todos los programadores Java, .NET y otros =) GL! – Marthin