Est-ce une mauvaise pratique d’append des éléments à List en utilisant la méthode getter en Java?

Je ne pense pas que ce soit une pratique particulièrement bonne de faire quelque chose comme:

 myObj.getMyList().add(x); 

puisque vous exposez une variable de classe privée de manière non lisible, cela dit, je la vois assez souvent (je vous regarde, les classes générées automatiquement). Je dirais qu’au lieu de procéder ainsi, renvoyer une liste non modifiable et permettre aux utilisateurs de la classe de s’append à la liste via une méthode explicite:

 public class MyClass{ private final List myList = new ArrayList(); public List getList(){ return Collections.unmodifiableList(this.myList); } public void addToList(final Ssortingng s){ this.myList.add(s); } } 

EDIT Après avoir passé en revue vos commentaires, je voudrais append quelques mots sur votre idée de setter:

Je voulais dire utiliser cette ligne de code dans un nouveau type de setter à l’intérieur de la classe, comme public set void (someElement) {this.myLinkedList.add (someElement);}

Si je vous ai bien compris, vous dites que vous souhaitez exposer une méthode qui ne fait qu’append à votre liste. Globalement, c’est ce que je pense que vous devriez viser, et ce que beaucoup ont souligné dans les réponses. Cependant, le qualifier de passeur est un peu trompeur puisque vous ne modifiez rien. Cela, et je recommande fortement de retourner si possible une liste en lecture seule à partir de votre méthode getter.

En général, vous ne devez pas supposer que la liste renvoyée par le getter est la liste originale. Il pourrait être décoré ou mandaté par exemple. Si vous souhaitez empêcher la création d’une nouvelle liste sur l’object cible, vous pouvez définir une méthode add sur la classe cible.

Dans ce cas, il serait préférable de suivre vos principes d’encapsulation et d’utiliser une méthode pour append des éléments à la liste. Vous avez un access restreint à votre liste en la rendant private afin que les autres classes ne puissent pas accéder directement au type de données.

Laissez la classe qui stocke votre ArrayList avoir un access direct à la liste, mais lorsque d’autres classes souhaitent s’append à la liste, utilisez une méthode add() .

Dès que vous avez une Collection , il n’est généralement pas mauvais d’append des méthodes telles que add() , remove() à l’interface de votre classe s’il est logique que les clients puissent append ou supprimer des objects de votre liste privée. .

La raison pour laquelle il est utile de mettre en œuvre ces méthodes supplémentaires (cela peut sembler excessif, car après toutes ces méthodes, la plupart du temps est simplement appelée dans la Collection ) est que vous empêchez les clients malveillants de modifier votre liste de choses à faire, car l’interface de la plupart des Collection contient plus que les méthodes add() et remove() , mais surtout que vous ne voulez pas que les clients fouillent avec des choses que vous ne pouvez pas contrôler. Par conséquent, le principe d’encapsulation est si important pour votre enseignant.

Un autre avantage: si, à un moment quelconque, vous décidiez qu’une certaine condition doit être remplie lorsqu’un object est ajouté à votre liste, cela peut facilement être implémenté dans la méthode que vous avez déjà. Si vous donnez à un client un access à la référence directe de votre liste, il n’est pas facile du tout de mettre en œuvre ce genre de choses (qui ne sont pas rares).

J’espère que cela t’aides

Cela dépend de l’application – les deux sont acceptables. Examinez bien la classe que vous écrivez et décidez si vous souhaitez autoriser les utilisateurs à accéder directement au contenu de la liste ou si vous préférez qu’ils passent d’abord par un processus intermédiaire.

Par exemple, supposons que vous ayez une classe ListEncrypter qui contient votre liste MyLinkedList . Le but de cette classe est de chiffrer tout ce qui est stocké dans MyLinkedList . Dans ce cas, vous souhaitez fournir une méthode d’ajout personnalisée afin de traiter l’élément ajouté avant de le placer dans la liste. Si vous souhaitez accéder à l’élément, vous devez également le traiter:

 public void add(Object element) { MyLinkedList.add(encrypt(element);); } public Object get(int index) { return decrypt(MyLinkedList.get(index);); } 

Dans ce cas, vous souhaitez clairement refuser à l’utilisateur l’access à la variable MyLinkedList , car le contenu sera crypté et ne pourra rien faire avec.

Par ailleurs, si vous n’effectuez aucun traitement de données ( et que vous n’êtes plus obligé de le faire à l’avenir ), vous pouvez ignorer la création de méthodes spécialisées et permettre uniquement à l’utilisateur d’accéder directement au contenu. la liste via la méthode get .

Si je comprends bien votre question, vous avez une classe contenant une List (elle devrait probablement être final , mais vous ne le mentionnez pas), et vous souhaitez autoriser les appelants à s’append à la List sans pouvoir la remplacer.

Vous pouvez soit fournir un getter pour la liste:

 public List getMyList() { return myList; } 

Ou fournissez une méthode pour append à cette liste:

 public void addToMyList(E e) { myList.add(e); } 

Les deux sont des décisions de conception valables, mais que vous utiliserez dépendra de votre cas d’utilisation. La première option donne aux appelants un access direct à la List , ce qui la rend effectivement publique. Ceci est utile lorsque les utilisateurs vont modifier et utiliser la liste de manière répétée, mais peut poser problème, car vous ne pouvez plus vous assurer que la List est dans un état fiable (l’appelant peut la vider, la réorganiser ou même insérer des objects de manière malveillante). d’un type différent). La première option ne doit donc être utilisée que lorsque vous avez l’intention de faire confiance à l’appelant.

La deuxième option donne moins de pouvoir à l’appelant, car il ne peut append qu’un seul élément à la fois. Si vous souhaitez fournir des fonctionnalités supplémentaires (insertion, ajout, tout, etc.), vous devrez encapsuler chaque opération. Mais cela vous donne plus de confiance, car vous pouvez être certain que la List ne sera modifiée que de la manière que vous approuvez. Cette dernière option masque également (encapsule) le détail de l’implémentation que vous utilisez une List . Par conséquent, si l’encapsulation est importante pour votre cas d’utilisation, vous souhaitez utiliser cette méthode pour éviter d’exposer vos structures de données internes et exposer uniquement le comportement. vous souhaitez accorder aux appelants.