Có phải là quá mức để bọc một bộ sưu tập trong một lớp đơn giản chỉ vì mục đích dễ đọc hơn?

Tôi có bản đồ sau:

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

Điều này HashMapánh xạ doublecác giá trị (là các điểm theo thời gian) vào SoundEvent'ô' tương ứng : mỗi 'ô' có thể chứa một số SoundEvents. Đó là lý do tại sao nó được thực hiện như một List<SoundEvent>, bởi vì đó chính xác là những gì nó được.

Để dễ đọc mã hơn, tôi đã nghĩ đến việc triển khai một lớp bên trong tĩnh rất đơn giản như vậy:

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
}

Và hơn là khai báo bản đồ (và rất nhiều mã khác) sẽ trông tốt hơn, ví dụ:

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

Đây có phải là quá mức cần thiết? Bạn sẽ làm điều này trong các dự án của bạn?

Nó không quá mức cần thiết. Bắt đầu với các thao tác bạn cần, thay vì bắt đầu bằng "Tôi có thể sử dụng HashMap". Đôi khi một HashMap chỉ là những gì bạn cần.
Trong trường hợp của bạn, tôi nghi ngờ là không. Những gì bạn có thể muốn làm là một cái gì đó như thế này:

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

Bạn chắc chắn không muốn có một loạt mã nói điều này:

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

Hoặc có lẽ bạn chỉ có thể sử dụng một trong các triển khai Guava Multimap .

Mặc dù nó có thể hỗ trợ khả năng đọc ở một số khu vực, nhưng nó cũng có thể làm phức tạp mọi thứ. Cá nhân tôi tránh xa việc gói hoặc mở rộng các bộ sưu tập vì mục đích lưu loát, vì trình bao bọc mới, khi đọc ban đầu, ngụ ý với tôi rằng có thể có hành vi tôi cần phải biết. Hãy coi đó là một sắc thái của Nguyên tắc bất ngờ tối thiểu.

Bám sát với việc thực hiện giao diện có nghĩa là tôi chỉ cần lo lắng về giao diện. Tất nhiên, việc triển khai cụ thể có thể là hành vi bổ sung, nhưng tôi không cần phải lo lắng về điều đó. Vì vậy, khi tôi đang cố gắng tìm đường đi qua mã của ai đó, tôi thích các giao diện đơn giản để dễ đọc hơn.

Mặt khác, nếu bạn đang tìm một trường hợp sử dụng có lợi từ hành vi được thêm vào, thì bạn có một đối số để cải thiện mã bằng cách tạo một lớp đầy đủ.

Việc gói nó giới hạn chức năng của bạn chỉ với những phương thức bạn quyết định viết, về cơ bản là tăng mã của bạn không có lợi. Ít nhất, tôi sẽ thử như sau:

private static class SoundEventCell : List<SoundEvent>
{
}

Bạn vẫn có thể viết mã từ ví dụ của bạn.

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

Điều đó nói rằng, tôi chỉ từng làm điều này khi có một số chức năng mà danh sách cần. Nhưng tôi nghĩ rằng phương pháp của bạn sẽ quá mức cho việc này. Trừ khi bạn có lý do để muốn giới hạn quyền truy cập vào hầu hết các phương thức của Danh sách.

Một giải pháp khác có thể là định nghĩa lớp trình bao bọc của bạn bằng một phương thức duy nhất hiển thị danh sách:

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

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

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

Điều này cung cấp cho bạn lớp được đặt tên tốt của bạn với mã tối thiểu, nhưng vẫn cung cấp cho bạn đóng gói, cho phép bạn ví dụ làm cho lớp không thay đổi (bằng cách thực hiện một bản sao phòng thủ trong hàm tạo và sử dụng Collections.unmodifiableListtrong trình truy cập).

(Tuy nhiên, nếu các danh sách này thực sự chỉ được sử dụng trong lớp này, tôi nghĩ rằng bạn nên thay thế Map<Double, List<SoundEvent>>bằng Multimap<Double, SoundEvent>( tài liệu ) của mình, vì điều đó thường giúp tiết kiệm rất nhiều logic và lỗi kiểm tra null.)