Est-ce exagéré d'envelopper une collection dans une classe simple uniquement pour une meilleure lisibilité?

J'ai la carte suivante:

Map<Double, List<SoundEvent>> soundEventCells = new HashMap<Double, List<SoundEvent>>();

Cela HashMapmappe les doublevaleurs (qui sont des points dans le temps) à la SoundEvent«cellule» correspondante : chaque «cellule» peut contenir un certain nombre de SoundEvents. C'est pourquoi il est implémenté en tant que List<SoundEvent>, car c'est exactement ce que c'est.

Pour une meilleure lisibilité du code, j'ai pensé à implémenter une classe interne statique très simple comme ceci:

private static class SoundEventCell {
    private List<SoundEvent> soundEvents = new ArrayList<SoundEvent>();
    public void addEvent(SoundEvent event){
        soundEvents.add(event);
    }
    public int getSize(){
        return soundEvents.size();
    }
    public SoundEvent getEvent(int index){
        return soundEvents.get(index);
    }
    // .. remove() method unneeded
}

Et que la déclaration de carte (et beaucoup d'autres codes) serait meilleure, par exemple:

Map<Double, SoundEventCell> soundEventCells = new HashMap<Double, SoundEventCell>();

Est-ce exagéré? Le feriez-vous dans vos projets?

Ce n'est pas du tout exagéré. Commencez par les opérations dont vous avez besoin, plutôt que de commencer par «Je peux utiliser un HashMap». Parfois, un HashMap est exactement ce dont vous avez besoin.
Dans votre cas, je pense que non. Ce que vous voulez probablement faire, c'est quelque chose comme ceci:

public class EventsByTime {
    public EventsByTime addEvent(double time, SoundEvent e);
    public List<SoundEvent> getEvents(double time);
    // ... more methods specific to your use ...
}

Vous ne voulez certainement pas avoir un tas de code disant ceci:

List<SoundEvent> events = eventMap.get(time);
if (events == null) {
   events = new ArrayList<SoundEvent>();
   eventMap.put(time, events);
}

Ou peut-être pourriez-vous simplement utiliser l'une des implémentations de Guava Multimap .

Bien qu'il puisse aider à la lisibilité dans certaines régions, il peut également compliquer les choses. Personnellement, je m'éloigne de l'emballage ou de l'extension des collections par souci de fluidité, car le nouveau wrapper, à la lecture initiale, implique pour moi qu'il peut y avoir un comportement dont je dois être conscient. Considérez cela comme une nuance du principe de la moindre surprise.

S'en tenir à la mise en œuvre de l'interface signifie que je n'ai qu'à me soucier de l'interface. L'implémentation concrète peut, bien sûr, abriter un comportement supplémentaire, mais je ne devrais pas avoir à m'en soucier. Donc, lorsque j'essaie de trouver mon chemin dans le code de quelqu'un, je préfère les interfaces simples pour la lisibilité.

Si, d'autre part, vous trouvez un cas d'utilisation qui fait bénéficier le comportement ajouté, alors vous avez un argument pour améliorer le code en créant une classe à part entière.

L'encapsuler limite votre fonctionnalité aux seules méthodes que vous décidez d'écrire, augmentant fondamentalement votre code sans aucun avantage. À tout le moins, j'essaierais ce qui suit:

private static class SoundEventCell : List<SoundEvent>
{
}

Vous pouvez toujours écrire le code de votre exemple.

Map<Double, SoundEventCell> soundEventCells = new HashMap<Double, SoundEventCell>();

Cela dit, je ne l'ai fait que lorsqu'il y a des fonctionnalités dont la liste elle-même a besoin. Mais je pense que votre méthode serait exagérée. Sauf si vous aviez une raison de vouloir limiter l'accès à la plupart des méthodes de List.

Une autre solution pourrait être de définir votre classe wrapper avec une seule méthode qui expose la liste:

private static class SoundEventCell
{
    private List<SoundEvent> events;

    public SoundEventCell(List<SoundEvent> events)
    {
        this.events = events;
    }

    public List<SoundEvent> getEvents()
    {
        return events;
    }
}

Cela vous donne votre classe bien nommée avec un code minimal, mais vous donne toujours l'encapsulation, vous permettant par exemple de rendre la classe immuable (en faisant une copie défensive dans le constructeur et en utilisant Collections.unmodifiableListdans l'accesseur).

(Cependant, si ces listes ne sont en effet utilisées que dans cette classe, je pense que vous feriez mieux de remplacer votre Map<Double, List<SoundEvent>>par un Multimap<Double, SoundEvent>( docs ), car cela économise souvent beaucoup de logique et d'erreurs de vérification nulle.)