¿Está mal usar un singleton como clase de administrador de datos?

Question

que comúnmente crear aplicaciones que requieren el almacenamiento de datos, y estos datos se utilizan en todo el programa. Aunque no es mucho, por lo general uso NSUserDefaults para cargar/guardar esta información. Sin embargo, el código de guardado/carga, junto con el empaque/desempaquetado de los datos, ocupa espacio, y pensé que mover este código a métodos reutilizables dentro de un singleton global sería una buena idea. Parece que funcionó bien.

Aún así, he leído mucho últimamente sobre los males de embarazos únicos y objetos globales, y he empezado a tener dudas. La gente a menudo dice que el uso de singletons es casi siempre una indicación de diseño pobre. En su mayor parte, estaría en desacuerdo (creo que los usos simples como este son un buen patrón de diseño), pero ciertamente no soy un experto en el tema.

Por lo tanto, es el uso de embarazos únicos, incluso de una manera tan simple como este mal? Si es así, ¿cuál es la mejor alternativa?

Answer 1

que definitivamente no están de acuerdo que son únicos mal. A veces se usan en exceso, pero en algunas ocasiones son perfectos para el trabajo. En algunas aplicaciones, tiene sentido tener algún tipo de administrador de datos en general. El patrón singleton se usa ampliamente en el SDK mismo (delegados de aplicaciones, administradores compartidos, centros predeterminados, etc.). En la mayoría de los casos, estos no son singleton "puros", ya que puede acceder a una instancia compartida, pero también puede crear instancias nuevas si es necesario.

La pregunta que debe hacerse es si sería útil tener acceso a una sola instancia de un administrador de datos desde cualquier lugar en cualquier momento; si no es así, probablemente no sea necesario un singleton. Sin embargo, si va a utilizar singletons en entornos de subprocesos múltiples, debe preocuparse por las condiciones de carrera (¿puede un hilo modificar un recurso mientras otro está accediendo a él?), La documentación tiene buenas explicaciones sobre cómo lograr esto en Cocoa. .

Déjame intentar explicar con un ejemplo: estoy usando algún código de un juego que escribí. Supongamos que tiene una clase GameMap y una clase Tile. El GameMap representa una cuadrícula de 2 dimensiones de objetos Tile.

GameMap *gameMap = [[GameMap alloc] init]; 
NSArray *theTiles = gameMap.tiles; 

La instancia de la GameMap propietaria de la red de azulejos, baldosas y crea el cuando se crea el mapa del juego. No se necesita singleton

Puede decir "pero solo tengo una GameMap a la vez, ¿cuál es el problema?". ¿Qué hay sobre cargar juegos guardados, o cargar nuevos niveles? Bueno, eso se vuelve tan fácil como:

// In whatever class object owns the game map 
self.gameMap = [[GameMap alloc] initWithSaveData:saveData]; 

En conclusión, crea una instancia de una clase que tenga código para administrar otras instancias de cosas. Manténgase lo menos global posible y su código será más escalable y mantenible.