Hola, encontramos la solución a tu pregunta, continúa leyendo y la hallarás más abajo.
Solución:
En términos más simples:
- Función determinista pura: La salida se basa completamente, y solo, en los valores de entrada y nada más: no hay otra entrada (oculta) o estado en el que se base para generar su salida. No hay efectos secundarios ni otros resultados.
- Función determinista impura: Al igual que con una función determinista que es una función pura: la salida se basa completamente, y solo, en los valores de entrada y nada más: no hay otra entrada o estado (oculto) en el que se base para generar su salida – sin embargo hay otra salida (efectos secundarios).
- Idempotencia: La definición práctica es que puede llamar de forma segura a la misma función varias veces sin temor a efectos secundarios negativos. Más formalmente: no hay cambios de estado entre llamadas idénticas posteriores.
La idempotencia no implica determinación (ya que una función puede alterar el estado en la primera llamada mientras es idempotente en las llamadas posteriores), pero todas las funciones deterministas puras son inherentemente idempotentes (ya que no existe un estado interno que persista entre las llamadas). Las funciones deterministas impuras no son necesariamente idempotentes.
Determinista puro | Determinista impuro | Puro no determinista | Impuro no determinista | Idempotente | |
---|---|---|---|---|---|
Aporte | Solo argumentos de parámetro (incl. this ) |
Solo argumentos de parámetro (incl. this ) |
Argumentos de parámetros y estado oculto | Argumentos de parámetros y estado oculto | Alguna |
Producción | Solo valor devuelto | Valor de retorno o efectos secundarios | Solo valor devuelto | Valor de retorno o efectos secundarios | Alguna |
Efectos secundarios | Ninguno | sí | Ninguno | sí | Después de la primera llamada: Quizás. Después de la segunda llamada: ninguna |
Ejemplo de SQL | UCASE |
CREATE TABLE |
GETDATE |
DROP TABLE |
|
Ejemplo de C # | String.IndexOf |
List |
DateTime.Now |
Random.Next |
Directory.Create [1] |
- [1] –
Directory.Create
es idempotente porque si el directorio ya existe, devuelve un nuevoDirectoryInfo
instancia como si acabara de crear un nuevo directorio del sistema de archivos (al igual queCreateFile
puede ser usado para abierto un archivo existente).
Determinación de funciones puras
Por ejemplo, en SQL UCASE(val)
, o en C # /. NET String.IndexOf
son deterministas porque la salida depende solo de la entrada. Tenga en cuenta que en los métodos de instancia (como IndexOf
) el objeto de instancia (es decir, el oculto this
parámetro) cuenta como entrada, aunque esté “oculta”:
"foo".IndexOf("o") == 1 // first cal
"foo".IndexOf("o") == 1 // second call
// the third call will also be == 1
Mientras que en SQL NOW()
o en C # /. NET DateTime.UtcNow
no es determinista porque la salida cambia a pesar de que la entrada sigue siendo la misma (tenga en cuenta que los captadores de propiedades en .NET son equivalentes a un método que no acepta parámetros además de los implícitos this
parámetro):
DateTime.UtcNow == 2016-10-27 18:10:01 // first call
DateTime.UtcNow == 2016-10-27 18:10:02 // second call
Idempotencia
Un buen ejemplo en .NET es el Dispose()
método: Consulte ¿Deben ser idempotentes las implementaciones de IDisposable.Dispose ()?
un método Dispose debe poder llamarse varias veces sin producir una excepción.
Entonces, si un componente principal X
hace una llamada inicial a foo.Dispose()
entonces invocará la operación de eliminación y X
ahora puedo considerar foo
para ser desechado. La ejecución / control luego pasa a otro componente Y
que luego también intenta deshacerse de foo
, después Y
llamadas foo.Dispose()
también puede esperar foo
para ser desechado (que es), aunque X
ya lo deseché. Esto significa Y
no necesita verificar para ver si foo
ya está eliminado, lo que ahorra tiempo al desarrollador y también elimina errores en los que se llama Dispose
una segunda vez podría generar una excepción, por ejemplo.
Otro ejemplo (general) está en REST: el RFC para HTTP1.1 establece que GET
, HEAD
, PUT
, y DELETE
son idempotentes, pero POST
no es (https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html)
Los métodos también pueden tener la propiedad de “idempotencia” en el sentido de que (aparte de errores o problemas de caducidad) los efectos secundarios de N> 0 solicitudes idénticas son los mismos que para una sola solicitud. Los métodos GET, HEAD, PUT y DELETE comparten esta propiedad. Además, los métodos OPTIONS y TRACE NO DEBEN tener efectos secundarios, por lo que son inherentemente idempotentes.
Entonces, si usas DELETE
luego:
Client->Server: DELETE /foo/bar
// `foo/bar` is now deleted
Server->Client: 200 OK
Client->Server DELETE /foo/bar
// foo/bar` is already deleted, so there's nothing to do, but inform the client that foo/bar doesn't exist
Server->Client: 404 Not Found
// the client asks again:
Client->Server: DELETE /foo/bar
// foo/bar` is already deleted, so there's nothing to do, but inform the client that foo/bar doesn't exist
Server->Client: 404 Not Found
Entonces ves en el ejemplo anterior que DELETE
es idempotente en el sentido de que el estado del servidor no cambió entre los dos últimos DELETE
solicitudes, pero no es determinista porque el servidor devolvió 200
para la primera solicitud pero 404
para la segunda solicitud.
Una función determinista es solo una función en el sentido matemático. Dada la misma entrada, siempre obtiene la misma salida. Por otro lado, una función idempotente es una función que satisface la identidad
f(f(x)) = f(x)
Como un simple ejemplo. Si UCase()
es una función que convierte un string a una mayúscula string, entonces claramente UCase(Ucase(s)) = UCase(s)
.
Las funciones idempotentes son un subconjunto de todas las funciones.
A determinista La función devolverá el mismo resultado para las mismas entradas, independientemente de cuántas veces la llame.
Un idempotente Es posible que la función NO devuelva el mismo resultado (devolverá el resultado en la misma forma, pero el valor podría ser diferente, consulte el ejemplo http a continuación). Solo garantiza que no tendrá efectos secundarios. En otras palabras, no cambiará nada.
Por ejemplo, el GET
verbo está destinado a ser idempotente en el protocolo HTTP. Si llama a “~ / employee / 1”, devolverá la información del empleado con ID 1 en un formato específico. Nunca debe cambiar nada, simplemente devolver la información del empleado. Si lo llama 10, 100 o más veces, el formato devuelto siempre será el mismo. Sin embargo, de ninguna manera puede ser determinista. Tal vez si lo llama por segunda vez, la información del empleado ha cambiado o tal vez el empleado ya no existe. Pero nunca debería tener efectos secundarios o devolver el resultado en un formato diferente.
Mi opinión
Idempotent es una palabra extraña, pero conocer el origen puede ser muy útil. ídem sentido mismo y potente sentido poder. En otras palabras, significa teniendo el mismo poder lo que claramente no significa que no efectos secundarios así que no estoy seguro de dónde viene eso. Un ejemplo clásico de Solo hay dos cosas difíciles en la informática, invalidación de caché y nombrar cosas. ¿Por qué no podían simplemente usar solo lectura? Oh, espera, ¿querían sonar extra inteligentes, tal vez? Tal vez como complejidad ciclomática?
Aquí tienes las comentarios y calificaciones
Te invitamos a añadir valor a nuestro contenido informacional aportando tu veteranía en las anotaciones.