2008-10-28 16 views
6

Me pregunto cuáles son las formas recomendadas para manejar situaciones en las que, en el código de memoria administrada, el objeto no pertenecía a ningún propietario en particular, es decir, los objetos puestos en libertad a sí mismos. Un ejemplo de este tipo podría ser una subclase de NSWindowController, que configura, muestra y gestiona la entrada y la salida de una sola ventana. El objeto del controlador muestra una ventana y se libera más tarde en algún momento (generalmente cuando la ventana o hoja que administra está cerrada). AppKit también ofrece ejemplos de pares: NSAnimation se conserva en startAnimation y se libera cuando se completa la animación. Otro ejemplo es NSWindow, que se puede configurar para que se libere cuando se cierra.objetos propiedad del mismo en Objective-C Recolección de Basura

En la aplicación de estos "auto de propiedad de" objetos a mí mismo, veo al menos tres patrones GC-safe diferentes, pero todos ellos tienen algunos inconvenientes.

a). Usando CFRetain/CFRelease.

objeto de propiedad de auto llama CFRetain en la auto antes de que comience su funcionamiento (por ejemplo, en el ejemplo de controlador de ventana antes de que aparezca la ventana). Luego llama a CFRelease() en sí mismo cuando está listo (por ejemplo, en el ejemplo del controlador de ventana después de cerrar la ventana).

Pros: Usuario del objeto no tiene que preocuparse de la gestión de memoria.
Contras: Un poco feo, ya que requiere el uso de funciones de administración de memoria, aunque estamos usando GC en código ObjC puro. Si no se llama a CFRelease(), la fuga puede ser difícil de localizar.

b). Evitar la expresión idiomática de propiedad propia con estructura de datos estática.

objeto se agrega en una estructura de datos (por ejemplo una matriz mutable estática) antes de que comience su operación y elimina en sí desde allí cuando se hace.

Pros: Usuario del objeto no tiene que preocuparse de la gestión de memoria. No hay llamadas a funciones de administración de memoria. Los objetos tienen propietario explícito. Las posibles fugas son fáciles de localizar.
Contras: Se necesita bloqueo si se pueden crear objetos a partir de diferentes subprocesos. Estructura de datos extra

c). Evitar el lenguaje de auto propiedad al requerir al usuario de un objeto que guarde una referencia al objeto (por ejemplo, en un ivar).

Pros: No hay llamadas a funciones de administración de memoria. Los objetos tienen propietario explícito.
Contras: El usuario del objeto debe mantener una referencia incluso si ya no necesita el objeto. Ivars extra.

¿Qué patrón usaría para manejar estos casos?

Respuesta

2

La recomendación de Apple es (c), pero me gusta el sonido de (b). Una estructura de datos estática le permite ocultar los detalles del GC del usuario de la API y evitar sumergirse en el nivel CFRetain/CFRelease. Como dices, también facilita la depuración y la prueba de unidad; si la estructura de datos estática aún hace referencia a un objeto después de que finaliza su tarea, usted sabe que hay un error.

5

Para a), la alternativa más idiomática a CFRetain(foo)/CFRelease(foo) es [[NSGarbageCollector defaultCollector] disableCollectorForPointer:foo]/[[NSGarbageCollector defaultCollector] enableCollectorForPointer:foo].

Cuestiones relacionadas