Блог

Java позволяет мне определить реализацию интерфейса, которая переопределяет его методы методами, возвращающими подклассы возвращаемого типа интерфейса. Например:

 public interface GoblinHorde {
    Collection<Goblin> getGoblins();
}

public final class UniqueGoblinHorde implements GoblinHorde {
    private Set<Goblins> currentGoblins = new HashSet<>();
    
    @Override
    public Set<Goblin> getGoblins() {
        return currentGoblins;
    }
} 
 

Для меня это имеет смысл, потому что это дает разработчикам возможность найти компромисс между удобством обслуживания кода и производительностью. Если вы собираетесь использовать результаты GoblinHorde#getGoblins() в качестве набора, у вас должна быть возможность объявить тип вашего GoblinHorde как impl вместо интерфейса. Это позволяет использовать возвращенный набор вместо ненужного создания нового набора из коллекции, которая уже является набором. Очевидно, что это происходит за счет кода, который в долгосрочной перспективе менее удобен для обслуживания, но бывают ситуации, когда это имеет смысл.

Однако Google, похоже, не всегда следует этой схеме. AbstractSetMultimap#asMap() Метод Guava 30.1.1 возвращает более общий Map<K, Collection<V>> вместо Map<K, Set<V>> и заходит так далеко, чтобы включить в Javadocs примечание, которое гласит: Note: The returned map's values are guaranteed to be of type Set. To obtain this map with the more specific generic type Map<K, Set<V>>, call Multimaps.asMap(SetMultimap) instead.

В чем причина необходимости использования вторичного статического вспомогательного метода?

Единственная причина, по которой я мог видеть, заключается в том, что ковариантные типы возврата не поддерживались до версии Java 1.5, выпущенной в сентябре 2004 года, поэтому тогда было невозможно вернуть более конкретный тип. Не уверен, когда была написана эта библиотека, но я могу только предположить, что она была написана, когда это не поддерживалось.

Я вижу единственную причину: они хотят сохранить возможность изменения реализации, чтобы List , например, возвращать a Set вместо a, и избежать взлома многих приложений, полагающихся на возвращаемый объект Map<K, Set<V>> . Конечно, это гипотетическое изменение, скорее всего, будет означать, что ваш код потребуется изменить, чтобы скорректировать вашу бизнес-логику (возможно, вы полагались на «функцию» без дубликатов» Set ), но, по крайней мере, ваш код все равно будет компилироваться (если вы не выполните какое-либо приведение).