Les méthodes doivent-elles être destructives dans les objets personnalisés?

Question

Je dois implémenter Java.Polynomial en tant que tâche scolaire. Une partie des méthodes est add (polynôme) , multiplier (polynôme) etc.

Dans le cas de quelque chose comme

p.add(q); // computes p + q

est-il préférable de retourner vide et de garder la somme des polynômes dans p? ou est-il préférable de retourner un polynôme et de conserver la valeur antérieure de p intacte?

Mon instinct me dit que je devrais faire ce qui suit

• implémente p.add (q) comme méthode "destructive" ... il ajoute q à la valeur de p et stocke la somme dans p
• implémente également une méthode statique Polynomial.add (p, q) qui renvoie la somme des polynômes.

Qu'en penses-tu?

Answer 1

Personnellement, j'aime beaucoup les types immuables. Je voudrais écrire p.plus (q) au lieu de p.add (q) et lui faire renvoyer un nouveau polynôme. L'immuabilité a de nombreux avantages, non seulement en termes de sécurité des threads (ce qui semble ne pas poser problème en l'occurrence), mais également en termes de raisonnement à propos de votre code. Il est beaucoup plus facile de prédire ce qui va se passer si vous savez que rien ne peut changer le contenu d'un objet sous vos pieds une fois que vous y avez mis une référence.

Answer 2

C'est une question de style. C’est généralement mieux (et "plus simple") lorsque les objets sont immuables, les méthodes ne sont donc pas "destructives". (ils ne sont pas des mutateurs, ils n'ont pas d'effets secondaires) mais renvoient une nouvelle instance avec la nouvelle valeur.

La classe immuable la plus connue est String.

Answer 3

"Il est préférable de renvoyer un polynôme et de conserver l'intégralité de la valeur précédente de p"

La vie est meilleure si vous faites en sorte que vos types numériques se comportent comme les autres nombres.

Le " destructeur " Les opérations sont un mal nécessaire lorsque vous devez optimiser les performances en réduisant les allocations de mémoire.

Le compromis est que votre traitement devient opaque en raison des changements d'état plus complexes dans les variables. Vous ne voulez pas de changement d'état caché; vous voulez que vos assignations de valeurs aux variables soient une grande chose évidente, de première classe, avec un genre de chose.

Answer 4

Donc tout le monde dit que vous devriez le rendre immuable, et à moins que des raisons de performances très spécifiques ne le rendent mutable (vous allez ajouter un milliard de polynômes à un seul et ne pas vouloir allouer de mémoire), immuabilité est le chemin à parcourir.

Si vous avez de véritables raisons de performances, vous souhaiterez peut-être une version destructive et une version non destructive, mais souvenez-vous, cela conduit à la confusion. Je pense que votre idée de surcharger ajoute à être destructrice ou non basée sur l'arité rendra les choses très, très déroutant. Mieux vaut tout rendre non destructif et faire une méthode addDestructive (poly p) si vous choisissez.

Answer 5

Même si vous faites le "destructeur" méthode, vous souhaiterez quand même renvoyer la nouvelle valeur pour permettre l’enchaînement des fonctions. Et, pour ce que cela vaut, face au même problème que BigInteger et BigDecimal, Sun a décidé de ne pas être destructeur.

Answer 6

Rendez-le immuable et configurez l'interface comme pour BigInteger (le cas échéant).

Answer 7

  

est-il préférable de retourner vide et de garder la somme des polynômes dans p?

Pas mal, pas nécessairement mieux non plus.

  

ou vaut-il mieux renvoyer un polynôme et conserver la valeur précédente de p intacte?

C’est mieux, moins de surprises et un code plus facile à comprendre et à maintenir. (bien que vous deviez créer plus de variables)

Answer 8

Un polynôme a une valeur fixe en termes de variables et n’a donc de sens que s’il est immuable. Renvoyez un nouveau polynôme pour vos opérations.