¿Es una mala práctica usar variables estáticas tipo C en Objective-C?

Todo lo que quiero hacer es hacer una class de utilidad para mi aplicación (captura de flujo) que toma la configuration de mi website. Quiero llamarlo desde otros files como un simple [RemoteConfig updateSettings];

Mi objective es utilizar esta utilidad de configuration remota sin hacer un object para cada situación en la que tomo configuraciones remotas.

La información sobre las variables y methods estáticos / de class en el Objetivo C es confusa y muy obstinada, así que después de muchos experimentos, esto funcionó. Pero parece gracioso, lo que me hace pensar que algo es incorrecto.

RemoteConfig.h simplemente declara el método + (void) updateSettings .

Este es mi RemoteConfig.m :

 #import "RemoteConfig.h" static NSMutableData* _configData; static NSString* url = @"http://local.namehidden.com:90/json.html"; static int try; @implementation RemoteConfig +(void) updateSettings { NSString *identifier = [[[UIDevice currentDevice] identifierForVendor] UUIDString]; //Create URL request NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:url] cachePolicy: NSURLRequestReloadIgnoringCacheData timeoutInterval: 10]; [request setHTTPMethod: @"POST"]; NSString *post = [NSString stringWithFormat:@"id=%@", identifier]; NSData *postData = [post dataUsingEncoding:NSUTF8StringEncoding]; [request setHTTPBody:postData]; NSURLConnection* connection = [NSURLConnection connectionWithRequest:request delegate:self]; [connection start]; } ///////////////////////////// DELEGATE METHODS /////////////////////////////////// +(void)connection:(NSConnection*)conn didReceiveResponse:(NSURLResponse*)response { if (_configData == NULL) { _configData = [[NSMutableData alloc] init]; } [_configData setLength:0]; NSLog(@"didReceiveResponse: responseData length:(%d)", _configData.length); } /// and so on... 

Parece funky, poniendo las variables de estilo C por encima de la implementación de @ interface / @. Mucha gente dice que intentan usar properties, algunos dicen que el método estático singleton trick, he visto una pequeña biblioteca que maneja singletons pero esta fue la solución más simple que encontré.

Mis preguntas-

  • ¿Es esto proverbialmente malo?
  • ¿Qué limitaciones tiene esto?
  • ¿Cuáles son las alternativas y qué es lo mejor?

¿Es esto proverbialmente malo? ¿Qué limitaciones tiene esto?

Las variables globales tienden a imponer un cierto set de restricciones:

  • a menudo no limpian sus resources de manera adecuada
  • no son seguros para subprocesss (por ejemplo, se pueden usar desde un subprocess o pueden introducir estado por subprocess)
  • pueden no necesariamente ser seguros anidar
  • pueden combatir algunos de estos problemas mediante la serialization de requestes, introduciendo una suspensión y locking excesivos.
  • se vuelven muy difíciles de 'extender' de manera segura (es decir, agregar variables globales lo hace más frágil)
  • Son difíciles de probar y pueden generar errores que son muy difíciles de reproducir.

¿Cuáles son las alternativas y qué es lo mejor?

Simplemente mueva esas variables a ivars y cree instancias de la class en lugar de depender del estado global. Entonces puede ampliar y resumir de una manera que no afectará significativamente a sus clientes.

Tenga en count que static NSString* const url = @"http://local.namehidden.com:90/json.html"; no sería una variable mutable ( const añadido). Entonces, solo es _configData e try cuál debería ser ivars.

Usar variables estáticas como esta no es less seguro que usar Singleton. Seguirá teniendo los mismos problemas con la security de los hilos, por ejemplo, A Singleton es más fácil de burlar, por lo que podría ser un beneficio con Singleton.

En ambos casos, está presentando un estado global mutable (el estado global inmutable no es problemático). Lo problemático que esto es depende de dónde en la jerarquía de llamadas existen estas variables. Si la mayoría de su código está construido encima de algunas funciones que cambian su salida en function de un estado mutable global, entonces eso dificulta la testing y el análisis del código.

Entonces, si introduce un estado mutable global, intente:

  1. Colóquelo lo más alto posible en su estratificación. Lo que sea lo más pequeño posible, otro código debería depender de este código.

  2. Asegúrese de que los cambios de estado no cambien la salida de las funciones que lo utilizan. Por ejemplo, el estado mutable global que solo es el almacenamiento en caching podría funcionar.

  3. Si el código total de su progtwig es pequeño, puede usar el estado global, ya que hay poca diferencia entre las variables globales en un progtwig de 500 líneas y las variables de miembro en una class de 500 líneas.