Comenzando por los conceptos básicos, aquí hay una definición informal de Registry:
Pero:
Dicho esto, puede ser útil comprender esta clase para poder trabajar con Tink de forma eficiente por el momento.
¿Qué sucede cuando llamas a getPrimitive() en un controlador de conjunto de claves? Reenvía tu
llamada a Registry1, que contiene objetos con métodos concretos para crear
y las primitivas, como una
a la clave AesGcm o a una instancia de ChunkedMac. La tarea de Registry es reenviar la llamada
al objeto correcto. Esto solo funciona si el objeto está registrado, por lo que
es importante registrar siempre las primitivas que usarás.
Pero ¿qué sucede si uso una biblioteca que ya registró las primitivas que necesito?
Ese es precisamente el problema. Y una de las razones por las que se quitó Registry En este caso, el código funciona solamente hasta que los autores de la biblioteca decidan no registres ese primitivo. En este punto, el código se rompe y el la razón no es evidente y confusa. Por lo tanto, siempre registre lo que usar. Por ejemplo, si deseas usar MAC en tu código Java, deberías lo siguiente en la fase de configuración:
MacConfig.register()
Este código garantiza que todos los objetos necesarios se registren en el lugares necesarios para que puedas usar el primitivo de MAC.
Hay una parte más de este problema. Es posible que algunas de tus dependencias se registren cosas que realmente no necesitas y preferirías no depender. Este es otra razón para quitar el registro global.
-
a la instancia singleton global de la clase Registry, para ser precisos. Utilizamos el nombre "Registro" de ambas, la clase y el singleton, indistintamente. ↩