En commençant par les bases, voici une définition informelle du Registre:
Mais :
Cela dit, il peut être utile de comprendre cette classe afin de travailler efficacement avec Tink pour le moment.
Que se passe-t-il lorsque vous appelez getPrimitive() sur un handleset de keyset ? Il transfère votre appel au registre1, qui contient des objets dotés de méthodes concrètes pour créer des clés et des primitives, telles qu'une clé AesGcm ou une instance ChunkedMac. La tâche du registre consiste à transférer l'appel vers le bon objet. Cela ne fonctionne que si l'objet est enregistré. C'est pourquoi il est important de toujours enregistrer les primitives que vous allez utiliser.
Mais que se passe-t-il si j'utilise une bibliothèque qui a déjà enregistré les primitives dont j'ai besoin ?
C'est précisément le problème. Et l'une des raisons pour lesquelles le Registre est supprimé. En effet, dans ce cas, votre code ne fonctionne que jusqu'à ce que les auteurs de la bibliothèque décident de ne plus enregistrer cette primitive. À ce stade, votre code ne fonctionne pas, et la raison n'est pas claire et déroutante. Par conséquent, enregistrez toujours ce que vous utilisez. Par exemple, si vous prévoyez d'utiliser MAC dans votre code Java, vous devez procéder comme suit lors de la phase de configuration:
MacConfig.register()
Ce code garantit que tous les objets nécessaires sont enregistrés aux emplacements nécessaires à l'utilisation de la primitive MAC.
Il y a un autre côté de ce problème. Certaines de vos dépendances peuvent enregistrer des éléments dont vous n'avez pas besoin et dont vous préférez ne pas dépendre. C'est une autre raison de supprimer le registre global.
-
à l'instance du singleton global du registre de classe, pour être précis. Nous utilisons le nom "Registre" pour les deux, la classe et le singleton, de manière interchangeable. ↩