Czy przesada jest zawijanie kolekcji do prostej klasy tylko ze względu na lepszą czytelność?

Mam następującą mapę:

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

Ten HashMapmapy doublewartości (które są punktami, w czasie) do odpowiadającej SoundEvent„komórki”: każdy z „komórek” może zawierać kilka SoundEventsekund. Dlatego jest zaimplementowany jako List<SoundEvent>, ponieważ właśnie tak jest.

Ze względu na lepszą czytelność kodu pomyślałem o zaimplementowaniu bardzo prostej statycznej klasy wewnętrznej, takiej jak:

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
}

I wtedy deklaracja mapy (i wiele innych kodów) wyglądałaby lepiej, na przykład:

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

Czy to przesada? Czy zrobiłbyś to w swoich projektach?

To wcale nie jest przesada. Zacznij od operacji, których potrzebujesz, a nie od „Mogę użyć HashMapy”. Czasami HashMap jest właśnie tym, czego potrzebujesz.
W twoim przypadku podejrzewam, że tak nie jest. To, co prawdopodobnie chcesz zrobić, to coś takiego:

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

Na pewno nie chcesz mieć dużo kodu mówiącego:

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

A może możesz po prostu użyć jednej z implementacji Guava Multimap .

Chociaż może to poprawić czytelność w niektórych obszarach, może również komplikować sytuację. Osobiście opieram się na pakowaniu lub rozszerzaniu kolekcji ze względu na płynność, ponieważ nowe opakowanie, podczas pierwszego czytania, sugeruje mi, że może istnieć zachowanie, o którym muszę wiedzieć. Rozważ to odcień zasady najmniejszej niespodzianki.

Trzymanie się implementacji interfejsu oznacza, że ​​muszę się tylko martwić o interfejs. Konkretne wdrożenie może oczywiście zawierać dodatkowe zachowanie, ale nie powinienem się tym martwić. Tak więc, gdy próbuję znaleźć drogę przez czyjś kod, wolę proste interfejsy dla czytelności.

Jeśli z drugiej strony znajdujesz przypadek użycia, który korzysta z dodatkowego zachowania, masz argument za poprawieniem kodu poprzez utworzenie pełnoprawnej klasy.

Zawijanie go ogranicza twoją funkcjonalność tylko do tych metod, które zdecydujesz się napisać, zasadniczo zwiększając kod bez żadnych korzyści. Przynajmniej spróbowałbym:

private static class SoundEventCell : List<SoundEvent>
{
}

Nadal możesz napisać kod ze swojego przykładu.

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

To powiedziawszy, robiłem to tylko wtedy, gdy potrzebna jest funkcjonalność, której sama lista potrzebuje. Ale myślę, że twoja metoda byłaby przesadna. Chyba że masz powód, aby chcieć ograniczyć dostęp do większości metod List.

Innym rozwiązaniem może być zdefiniowanie klasy opakowania za pomocą jednej metody, która wyświetla listę:

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

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

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

Daje to dobrze znaną klasę z minimalnym kodem, ale wciąż zapewnia enkapsulację, co pozwala np. Uczynić klasę niezmienną (poprzez wykonanie kopii obronnej w konstruktorze i użycie Collections.unmodifiableListw akcesorium).

(Jednakże, jeśli te listy są rzeczywiście wykorzystywane tylko w tej klasie, myślę, że zrobisz lepiej zastąpić Map<Double, List<SoundEvent>>z Multimap<Double, SoundEvent>( docs ), jako że często oszczędza dużo zerowej sprawdzania logiki i błędów).