Les tuples doivent-ils se sous-classer les uns les autres ?

Question

Étant donné un ensemble de classes de tuple dans un langage OOP : Pair, Triple et Quad, est-ce que Triple devrait sous-classer Pair, et Quad sous-classer Triple ?

La question, à mon sens, est de savoir si un triple doit pouvoir être remplacé par une paire, et de même un quad pour un triple ou une paire. La question de savoir si un triple est également une paire et un quadruple est également un triple et une paire.

Dans un certain contexte, une telle relation peut être utile pour l'extensibilité - aujourd'hui, cette chose renvoie une paire de choses, demain j'aurai besoin qu'elle renvoie un triple sans interrompre les appelants existants, qui n'utilisent que les deux premiers des trois.

D'autre part, doivent-ils être des types distincts ? Je vois l'intérêt d'un contrôle de type plus fort - où l'on ne peut pas passer un Triple à une méthode qui attend un Pair.

Je penche pour l'utilisation de l'héritage, mais j'apprécierais vraiment l'avis d'autres personnes ?

PS : Au cas où cela aurait de l'importance, les classes seront (bien entendu) génériques.

PPS : D'un point de vue beaucoup plus subjectif, les noms devraient-ils être Tuple2, Tuple3 et Tuple4 ?

---

Edit : Je pense à ces groupes plutôt comme des groupes à couplage lâche ; pas spécifiquement pour des choses comme les coordonnées x/y x/y/z, bien qu'ils puissent être utilisés pour cela. Il s'agirait de choses comme le besoin d'une solution générale pour des valeurs de retour multiples d'une méthode, mais sous une forme avec une sémantique très simple.

Cela dit, je suis intéressé par toutes les façons dont les autres ont utilisé les tuples.

Answer 1

Il me semble que vous devriez créer une interface Tuple générique (ou utiliser quelque chose comme la Collection mentionnée ci-dessus), et faire en sorte que vos classes de paires et de 3-tuple implémentent cette interface. De cette façon, vous pouvez profiter du polymorphisme mais aussi permettre à une paire d'utiliser une implémentation plus simple qu'un tuple de taille arbitraire. Vous voudrez probablement que votre interface Tuple inclue les accesseurs .x et .y comme raccourci pour les deux premiers éléments, et les tuples plus grands peuvent implémenter leurs propres raccourcis comme il convient pour les éléments avec des indices plus élevés.

Answer 2

Cela dépend de la sémantique dont vous avez besoin -

• une paire d'opposés n'est pas sémantiquement compatible avec un triplet d'objets similaires
• une paire de coordonnées dans l'espace polaire n'est pas sémantiquement compatible avec un triplet de coordonnées dans l'espace euclidien

si votre sémantique consiste en de simples compositions, alors une classe générique Tuple<N> aurait plus de sens

Answer 3

Une longueur différente d'un tuple correspond à un type différent. (Dans un langage fortement typé, je ne pense pas qu'ils devraient être une collection.

C'est une bonne chose, car cela garantit une plus grande sécurité. Les endroits où vous retournez des tuples contiennent généralement des informations couplées, la connaissance implicite de ce qu'est chaque composant. C'est pire si vous passez plus de valeurs dans un tuple que prévu -- qu'est-ce que cela est supposé signifier ? Cela ne correspond pas à l'héritage.

Un autre problème potentiel se pose si vous décidez d'utiliser la surcharge. Si les tuples héritent les uns des autres, la résolution de la surcharge échouera là où elle ne devrait pas. Mais il s'agit probablement d'un meilleur argument contre la surcharge.

Bien sûr, tout cela n'a pas d'importance si vous avez un cas d'utilisation spécifique et que vous trouvez que certains comportements vous aideront.

Edit : Si vous voulez des informations générales, essayez de parcourir un peu Haskell ou la famille ML (OCaml/F#) pour voir comment ils sont utilisés et ensuite prendre vos propres décisions.

Answer 4

Comme pour la plupart des questions relatives à la conception, la réponse est : cela dépend.

Si vous recherchez une conception conventionnelle de Tuple, Tuple2, Tuple3, etc. est la voie à suivre. Le problème de l'héritage est que, tout d'abord, le triplet n'est pas un type de paire. Comment implémenter la méthode equals pour ce type de triplet ? Un triplet est-il égal à une paire dont les deux premiers éléments sont identiques ? Si vous avez une collection de paires, pouvez-vous y ajouter un triplet ou vice versa ? Si, dans votre domaine, cela ne pose pas de problème, vous pouvez opter pour l'héritage.

Quoi qu'il en soit, il est utile d'avoir une interface/classe abstraite (peut-être Tuple) que tous ces éléments implémentent.

Answer 5

Je choisirais 0, 1, 2 ou l'infini. Par exemple, null, 1 objet, votre classe Pair, ou une collection quelconque.

Votre Pair pourrait même implémenter une interface Collection.

S'il existe une relation spécifique entre trois ou quatre éléments, elle devrait probablement être nommée.

[Peut-être que le problème m'échappe, mais je n'arrive pas à imaginer un cas où je voudrais lier spécifiquement 3 choses de manière générique].