Java, объявите переменную с несколькими интерфейсами?

Вы можете сделать это с помощью дженериков, но это не очень красиво :

class MyClass<T,K,V extends Serializable & Map<K,V>> {

   T myVar;

}

Это можно сделать, используя некоторые уловки обобщения:

    public <T extends Map<?,?> & Serializable> void setMap(T map)

В приведенном выше коде используются обобщения, чтобы заставить вас передать карту, которая реализует оба интерфейса. Однако обратите внимание, что следствием этого является то, что когда вы фактически передаете ему карты, они, вероятно, должны быть либо помечены как сериализуемые, либо как тип карты, который уже сериализуем. Его также немного сложнее читать. Я хотел бы задокументировать, что карта должна быть сериализуемой, и провести для этого тест.

public interface MyMap extends Map, Serializable {
}

будет определять новый интерфейс, который представляет собой объединение Map и Serializable .

Вам, очевидно, необходимо затем предоставить подходящую реализацию этого (например, MyMapImpl ), и затем вы можете предоставить ссылки на переменные типа MyMap (или Map , или Serializable , в зависимости от требований.

В ответ на ваше пояснение, вы не можете модифицировать поведение (например, сериализуемую карту). У вас есть , чтобы иметь интерфейс и некоторую соответствующую реализацию.

Вы можете добиться этого, создав свой собственный интерфейс, который расширяет нужные вам интерфейсы

public interface SerializableMap<K, V> extends Map<K, V>, Serializable {

}

Я проголосовал за ответ Брайана, но хотел добавить немного более высокого уровня мысли ..

Если вы посмотрите SDK, вы найдете что они редко (если вообще когда-либо) передают реальные объекты коллекций.

Причина в том, что это не очень хорошая идея. Коллекции крайне незащищены.

Большую часть времени вы хотите сделать копию перед ее передачей и передать копию, чтобы любые изменения в коллекции не изменили среду для чего-то еще, что ' полагается на это. Кроме того, многопоточность становится кошмаром - даже с синхронизированной коллекцией!

Я видел два решения, одно - всегда извлекать массив и передавать его. Вот как это делает SDK.

Другой - ВСЕГДА обертывать коллекции в родительский класс (я имею в виду инкапсулировать, а не расширять). Я приобрел эту привычку, и это того стоит. На самом деле это ничего не стоит, потому что вы все равно не дублируете все методы сбора (на самом деле вы редко дублируете какие-либо из них). Фактически, вы в конечном итоге переносите функциональность «Утилита» из других классов, распределенных по всему вашему коду, в класс-оболочку, где она должна была быть в первую очередь.

Любой метод с сигнатурой, соответствующей методу (коллекция,...)" почти наверняка должен быть методом-членом этой коллекции, как и любые циклы, которые повторяются по коллекции.

Мне просто нужно время от времени выкидывать это, потому что это одна из тех вещей, которые я не получал некоторое время ( потому что никто не поддерживал эту концепцию). Всегда кажется, что у него будет какой-то недостаток, но, сделав это какое-то время и увидев проблемы, которые он решает, и код, который он устраняет, я сам даже не могу представить какие-либо возможные недостатки, это просто все хорошо.

Вы не сможете этого сделать, если хотите продолжать использовать существующие реализации Map .

Альтернативой может быть создание вспомогательного класса и добавление метод вроде этого:

public static Serializable serializableFromMap(Map<?, ?> map) {
    if (map instanceof Serializable) {
        return (Serializable)map;
    }
    throw new IllegalArgumentException("map wasn't serializable");
}

Нет, вам в значительной степени потребуется приведение.