2010-05-21 8 views
1

Je suis supposé créer une classe qui devrait être un conteneur pour un intervalle de valeurs (comme en mathématiques). J'ai déjà décidé que je vais utiliser en interne un SortedSet. Une des choses que je suis supposé implémenter est une méthode qui "obtient un ensemble ordonné avec tous les éléments dans l'intervalle".Problème déterminant le type de retour d'une méthode qui renvoie un SortedSet

class Interval { 
    private SortedSet sortedSet = new something(); 

    ... 

    <<method that should return an ordered set of values>> 
} 

Ma question réside dans ce qui devrait être à la fois le type de retour et le nom de la méthode. Plusieurs hypothèses se posent:

  1. SortedSet getSortedElements(); J'utilise en interne un SortedSet, donc je dois retourner ce type. Je devrais indiquer cette intention dans le nom de la méthode.
  2. SortedSet getElements(); Je utilise en interne un SortedSet, mais cela ne sert à rien d'indiquer que dans le nom de la méthode (je ne vois pas de gros point dans celui-ci).
  3. Set getElements(); Je devrais essayer de toujours retourner le type le plus basique, donc je retourne un Set. Par le contrat et la définition de la méthode, les gens savent déjà que tous les éléments sont en ordre.
  4. Set getSortedElements(); Pour le type de retour de méthode, identique à ci-dessus. A propos du nom de la méthode, vous indiquez clairement ce que cette méthode va renvoyer: un ensemble d'éléments triés.

Je suis enclin à utiliser 4., mais les autres semblent également bien. Y a-t-il un gagnant clair? Pourquoi?

+0

Je ne comprends pas votre question. SortedSet implémente déjà ce dont vous avez besoin avec 'public SortedSet sous-ensemble (E fromElement, E toElement)' – Pyrolistical

+0

Re. le nom de la méthode, "Elements" est trop générique. le nom de la méthode devrait être plus descriptif que " Elements" ... surtout si un jour vous avez besoin d'ajouter une autre collection à la classe, alors getElements devient ambigu – inor

Répondre

4

SortedSet est une interface avec le contrat que les éléments sont triés. Il expose également certaines méthodes non disponibles dans Set (telles que first()). Si vous êtes censé renvoyer un objet qui obéit à ce contrat (par exemple, renvoie des valeurs ordonnées sur iterator()), vous devez renvoyer un Sorted Set. Si ce n'est pas le cas, vous devez retourner un Set (ou un Collection).

Vous déterminez ce qu'il faut retourner en fonction de la façon dont vous voulez que le résultat soit utilisé. Pensez à ce que «obtient un ensemble ordonné avec tous les éléments de l'intervalle» signifie d'abord, puis s'inquiéter de la mise en œuvre.

Par ailleurs le code

private SortedSet sortedSet = new SortedSet(); 

est illégal, parce que SortedSet est une interface. Puisque c'est devoirs je vous laisserai pour comprendre pourquoi c'est un problème.

+1

+1 Le type de valeur retournée et le type de paramètres doivent refléter autant que possible le contrat. Et en passant, rendre les types de paramètres moins spécifiques et le type renvoyé plus spécifique est généralement pratique pour l'appelant. –

+0

oui, pendant que vous écrivez le post je suis passé à "quelque chose" bien que je vais utiliser un TreeSet. –

1

Je pense que renvoyer un Set est la bonne façon d'opter pour la maintenabilité - mais je n'aime pas les noms de méthodes. Pourquoi pas quelque chose de plus descriptif comme:

Set getIntervalValues(); 

ou quelque chose là-bas.

+0

J'aime le nom de la méthode. –

+0

Pourquoi Set est-il plus pratique pour l'appelant lorsque la méthode renvoie un SortedSet? Je pense le contraire: si l'appelant veut utiliser le résultat en tant que SortedSet, il lui suffit d'assigner le résultat à un SortedSet. Si elle ne se soucie pas de la commande, elle peut assigner le résultat à un Set. Maintenant, si le type de retour de la méthode est Set, un appelant qui veut l'utiliser en tant que SortedSet (par exemple appel first() etc.) devra le lancer - semble laid et risqué - et si l'implémenteur décide de changer l'implémentation en ensemble non-trié? – inor

+0

je vous ai donné +1 parce que je suis d'accord avec la partie sur le nom de la méthode – inor

0

Si la méthode est supposée renvoyer un SortedSet, cela devrait être le type de retour de la méthode. Les appelants peuvent affecter le résultat à un SortedSet ou à un Set, selon qu'ils se soucient de la commande ou non. si votre méthode javadoc ou nom implique que vous renvoyez un ensemble trié mais que le type de retour de votre méthode n'est que Set, c'est comme dire à votre plombier que vous lui paierez 100 $ pour ses services, mais écrivez alors dans le contrat que vous le paierez "au moins 50 $".

En retournant SortedSet
1) vous promettez à vos clients que vous êtes et que vous allez retourner un ensemble trié. vous ne pouvez pas changer ce contrat (pour définir) sans casser le code de votre client (ne compilera pas).
Si le type de retour de votre méthode est Set, peu importe ce que vous promettez vos clients/appelants dans votre javadoc ou dans le nom de la méthode, vous pouvez toujours modifier l'implémentation à tout moment pour renvoyer un ensemble non trié . Si le type de retour est Set et que l'appelant veut les fonctionnalités SortedSet, il peut convertir la valeur retournée en SortedSet (laid) mais un jour si vous décidez que vous allez juste retourner un Set (still) Set non trié, votre le code des appelants se brisera au moment de l'exécution (très risqué pour vos clients, imaginez que le code de vos clients fonctionne bien et qu'ils mettent à jour la bibliothèque que vous avez fournie ...).
2) les appelants peuvent avoir besoin d'un ensemble trié de vos résultats. Si vous retournez Set, ils pourraient être tentés de trier à nouveau votre résultat (voudriez-vous le demander pour lire votre javadoc?). Si vous renvoyez SortedSet, ils savent qu'ils n'ont pas besoin de re-trier.