Patrón de desecho

En la programación orientada a objetos , el patrón `dispose` es un patrón de diseño para la gestión de recursos . En este patrón, un objeto retiene un recurso y lo libera mediante la llamada a un método convencional ( generalmente llamado ` dispose` , ` removeclosedisposefreerelease

El patrón Dispose se utiliza principalmente en lenguajes cuyo entorno de ejecución cuenta con recolección automática de basura (véase la motivación a continuación).

Un problema clave del patrón Dispose es que, si disposeno se llama al método, se produce una fuga de recursos. Una causa común de esto es la salida prematura de una función, debido a un retorno anticipado o una excepción.

Por ejemplo:

from typing import Any , TextIOdef func ( filename : str ) -> Any : f = open ( filename ) if a : return x f . close () return y

Si la función devuelve un valor en el primer retorno, el archivo nunca se cierra y se produce una fuga de recursos.

from typing import TextIOdef func ( filename : str ) -> None : f : TextIO = open ( filename ) g ( f ) # Hacer algo con f que puede generar una excepción. f . close ()

Si el código intermedio genera una excepción, la función finaliza prematuramente y el archivo nunca se cierra, por lo que se produce una fuga de recursos.

Ambas situaciones pueden ser manejadas por una try...finallyestructura que garantiza que la cláusula finally siempre se ejecute al salir:

from typing import TextIOdef func ( filename : str ) -> None : try : f : TextIO = open ( filename ) # Hacer algo. finally : f . close ()

De forma más genérica:

Resource resource = getResource (); try { // El recurso ha sido adquirido; realizar acciones con el recurso. ... } finally { // Liberar el recurso, incluso si se produjo una excepción. resource.dispose ( ) ; }

Esta try...finallyestructura es necesaria para garantizar la seguridad ante excepciones , ya que el finallybloque permite la ejecución de la lógica de limpieza independientemente de si se produce o no una excepción en dicho trybloque.

Una desventaja de este enfoque es que requiere que el programador agregue explícitamente código de limpieza en un finallybloque. Esto provoca un aumento excesivo del tamaño del código y, de no hacerlo, se producirá una fuga de recursos en el programa.

Para que el uso seguro del patrón Dispose sea menos verboso, varios lenguajes cuentan con algún tipo de soporte incorporado para los recursos que se mantienen y liberan en el mismo bloque de código .

En C++ , la eliminación de recursos se realiza tradicionalmente mediante el patrón de adquisición de recursos mediante inicialización (RAII), por ejemplo, utilizando punteros inteligentes . Una vez que un recurso sale del ámbito, se llama a su destructor .

El lenguaje C# incluye la usinginstrucción ^{[ 2 ]} que llama automáticamente al Dispose()método en un objeto que implementa la System.IDisposableinterfaz :

using ( Resource resource = GetResource ()) { // Realizar acciones con el recurso. // ... }

lo cual es igual a:

usando el sistema ;Resource resource = GetResource () try { // Realizar acciones con el recurso. // ... } finally { // Es posible que el recurso no se haya adquirido o que ya se haya liberado if ( resource != null ) { (( IDisposable ) resource ) .Dispose (); } }

De manera similar, el lenguaje Pythonwith tiene una instrucción que puede usarse con un efecto similar con un objeto gestor de contexto . El protocolo del gestor de contexto requiere la implementación __enter__de __exit__métodos que son llamados automáticamente por la withconstrucción de la instrucción, para evitar la duplicación de código que de otro modo ocurriría con el patrón try/ . ^{[ 3 ]}finally

con resource_context_manager () como recurso : # Realizar acciones con el recurso. ... # Realizar otras acciones donde se garantiza que el recurso se desasignará. ...

El lenguaje Java introdujo una nueva sintaxis llamada try-with-resources en la versión 7 de Java. ^{[ 4 ]} Se puede utilizar en objetos que implementan la java.lang.AutoCloseableinterfaz (que define el método close()):

import java.io.IOException ; import java.io.OutputStream ;try ( OutputStream config = new OutputStream ( "configs/config.txt" )) { // Hacer algo con 'config' } catch ( IOException e ) { // Manejar la excepción// El recurso 'config' se cierra automáticamente }

En Rust , la semántica de eliminación se realiza mediante un rasgo std::ops::Drop, que destruirá automáticamente el objeto después de salir del ámbito. Se puede llamar manualmente mediante std::mem::drop().

Más allá del problema fundamental de la correcta gestión de recursos en presencia de devoluciones y excepciones, y la gestión de recursos basada en el montón (eliminar objetos en un ámbito distinto al de su creación), existen muchas otras complejidades asociadas al patrón de eliminación. Estos problemas se evitan en gran medida con RAII . Sin embargo, en el uso común y sencillo, estas complejidades no se presentan: se adquiere un único recurso, se realiza alguna acción con él y se libera automáticamente.

Un problema fundamental es que tener un recurso ya no es una invariante de clase (el recurso se mantiene desde la creación del objeto hasta que se elimina, pero el objeto sigue activo en ese momento), por lo que el recurso puede no estar disponible cuando el objeto intenta usarlo, por ejemplo, al intentar leer un archivo cerrado. Esto significa que todos los métodos del objeto que usan el recurso pueden fallar, concretamente, generalmente devolviendo un error o generando una excepción. En la práctica, esto es menor, ya que el uso de recursos también puede fallar por otras razones (por ejemplo, al intentar leer más allá del final de un archivo), por lo que estos métodos ya podrían fallar, y no tener un recurso solo añade otro posible fallo. Una forma estándar de implementar esto es agregar un campo booleano al objeto, llamado disposed, que se establece en verdadero mediante dispose, y se comprueba mediante una cláusula guard en todos los métodos (que usan el recurso), generando una excepción (como ObjectDisposedExceptionen .NET) si el objeto se ha eliminado. ^{[ 5 ]}

Además, es posible llamar disposea un objeto más de una vez. Si bien esto puede indicar un error de programación (cada objeto que contiene un recurso debe ser liberado exactamente una vez), es más simple, más robusto y, por lo tanto, generalmente preferible que disposesea idempotente (lo que significa "llamar varias veces es lo mismo que llamar una vez"). ^{[ 5 ]} Esto se implementa fácilmente usando el mismo disposedcampo booleano y comprobándolo en una cláusula guard al comienzo de dispose, en ese caso devolviendo inmediatamente, en lugar de generar una excepción. ^{[ 5 ]} Java distingue los tipos desechables (aquellos que implementan AutoCloseable^{[ 6 ]} ) de los tipos desechables donde dispose es idempotente (el subtipo Closeable^{[ 7 ]} ).

La disposición de recursos en presencia de herencia y composición de objetos que contienen recursos presenta problemas análogos a la destrucción/finalización (mediante destructores o finalizadores). Además, dado que el patrón `dispose` generalmente no cuenta con soporte del lenguaje para esto, se requiere código repetitivo . En primer lugar, si una clase derivada sobrescribe un disposemétodo en la clase base, el método sobrescritor en la clase derivada generalmente necesita llamar al disposemétodo en la clase base para liberar correctamente los recursos que contiene la base. En segundo lugar, si un objeto tiene una relación de "tiene un" con otro objeto que contiene un recurso (es decir, si un objeto usa indirectamente un recurso a través de otro objeto que lo usa directamente), ¿debe el objeto que usa indirectamente ser desechable? Esto corresponde a si la relación es de propiedad ( composición de objetos ), de visualización ( agregación de objetos ) o incluso simplemente de comunicación ( asociación ), y se encuentran ambas convenciones (el usuario indirecto es responsable del recurso o no lo es). Si el uso indirecto es responsable del recurso, debe ser desechable y deshacerse de los objetos de los que es propietario cuando se deshace (análogo a la destrucción o finalización de objetos de propiedad).

La composición (propiedad) proporciona encapsulación (solo es necesario rastrear el objeto que se utiliza), pero a costa de una complejidad considerable cuando existen relaciones adicionales entre objetos, mientras que la agregación (visualización) es considerablemente más simple, a costa de carecer de encapsulación. En .NET , la convención es que solo el usuario directo de los recursos sea responsable: "Debe implementar IDisposable solo si su tipo utiliza recursos no administrados directamente". ^{[ 8 ]} Consulte la administración de recursos para obtener más detalles y ejemplos.

• Vida útil del objeto
• La adquisición de recursos es la inicialización (RAII)

• Red de desarrolladores de Microsoft: Patrón de eliminación