Existe-t-il un modèle général pour représenter les cardinalités sur les champs ?
Bien entendu, vous pouvez représenter les cardinalités à l'aide de champs entiers, soit dans les objets eux-mêmes, soit au niveau méta. Mais cela ne sert pas à grand-chose si vous ne pouvez pas les appliquer.
Il n'y a pas de modèle général pour cela. La réponse de @Andy Turner fournit un bon résumé des alternatives sur l'application des cardinalités. Je voudrais juste ajouter quelques points :
-
Il est peu probable que l'on parvienne à faire respecter les contraintes de cardinalité par le biais d'un typage statique. Le système de types de Java n'est pas assez riche pour le faire de manière agréable 1 .
-
La construction d'objets dont les champs ont des cardinalités minimales peut s'avérer délicate, surtout s'il existe des circularités potentielles impliquant ces champs.
Une façon de traiter la construction est de séparer le cycle de vie des objets en une phase de "construction" et une phase "achevée". Au cours de la phase de construction, les contraintes sont relâchées afin de permettre une construction par étapes. À un moment donné, l'interrupteur "achevé" est "basculé". À ce moment-là, 1) les contraintes de cardinalité sont vérifiées et 2) le comportement des opérations de mutation est modifié pour empêcher les changements qui violeraient la cardinalité.
Cela peut être mis en œuvre à l'aide de constructeurs publics et d'une méthode publique permettant d'actionner l'interrupteur. Vous pouvez également utiliser la méthode modèle de construction ; par exemple
- rendre les constructeurs privés
- utiliser des moyens privés alternatifs pour contourner les cardinalités tout en construisant
- vérifier les cardinalités et basculer l'interrupteur (s'il y en a un) dans l'espace de travail.
build()
méthode.
Une autre approche consiste à permettre pour qu'ils soient inférieurs à la cardinalité, mais n'autorisent l'ajout d'éléments dans les champs que lorsqu'ils sont dans cet état. En d'autres termes, il s'agit de l'approche "basculer l'interrupteur" sans interrupteur explicite. L'inconvénient est qu'un client doit tester si la contrainte de cardinalité est déjà en vigueur, c'est-à-dire si la contrainte est faible.
1 - En théorie, vous pourriez mettre en place un ListOfTwoOrMore
mais cela entraînerait une série de nouveaux problèmes.