仅出于更好的可读性而将集合包装在一个简单的类中是否为时过早？

我有以下地图：

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

这HashMap会将double值（它们是时间点）映射到相应的SoundEvent“单元格”：每个“单元格”可以包含多个SoundEvent。这就是为什么将其实现为的原因List<SoundEvent>，因为这正是它的本质。

为了提高代码的可读性，我考虑过实现一个非常简单的静态内部类，如下所示：

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
}

并且比地图声明（以及许多其他代码）看起来更好，例如：

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

这是过度杀伤力吗？您会在项目中这样做吗？

一点也不算过分。从所需的操作开始，而不是从“我可以使用HashMap”开始。有时，HashMap正是您所需要的。
就您而言，我怀疑并非如此。您可能想做的是这样的：

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

您绝对不希望有一堆这样的代码：

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

或者，您可以只使用一种Guava Multimap实现。

虽然它在某些方面可能有助于可读性，但也可能使事情复杂化。为了流利，我个人不希望包装或扩展收藏，因为新包装在最初阅读时对我意味着可能需要注意一些行为。认为它是“最少惊讶原则”的阴影。

坚持使用接口实现意味着我只需要担心接口。当然，具体的实现可能包含其他行为，但是我不必担心。因此，当我尝试通过某人的代码找到自己的方式时，我更喜欢普通的界面以提高可读性。

另一方面，如果您发现确实可以从增加的行为中受益的用例，则可以通过创建完整的类来改进代码。

包装它会将您的功能限制为仅决定决定编写的那些方法，基本上没有任何好处地增加了代码。至少，我会尝试以下方法：

private static class SoundEventCell : List<SoundEvent>
{
}

您仍然可以从示例中编写代码。

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

就是说，只有在列表本身需要某些功能时，我才这样做。但是我认为您的方法对此会显得过大。除非您有理由要限制对大多数List方法的访问。

另一个解决方案可能是使用公开列表的单个方法定义包装器类：

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

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

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

这使您可以用最少的代码来命名类，但是仍然可以进行封装，例如，使类不可变（通过在构造函数中进行防御性复制并Collections.unmodifiableList在访问器中使用）。

（但是，如果这些列表确实仅在此类中使用，我认为您最好Map<Double, List<SoundEvent>>用Multimap<Double, SoundEvent>（docs）替换您的列表，因为这样通常可以节省很多空检查逻辑和错误。）