Соглашение о печати для локальных коллекций в Java - PullRequest
2 голосов
/ 19 августа 2010

Я недавно натолкнулся на набор кода, который создавал локальные карты следующим образом:

HashMap<String, Object> theMap = new HashMap<String, Object>();

Как правило, когда я видел, как HashMaps использовали (и использовал их сам), локальные переменные просто Map (интерфейс), а не привязаны к конкретной реализации. Очевидно, что это необходимо, если Map потенциально может быть создан как различные Map типы (например, принимая параметр). Однако, в случае чего-то подобного выше, где это определено и реализовано в одной и той же точке, есть ли основная причина использовать только тип интерфейса, или это просто стиль / соглашение?

Ответы [ 4 ]

7 голосов
/ 19 августа 2010

(Первоначально я неправильно понял вопрос, основанный на названии, но я включил соглашения как по типу, так и по переменной, поскольку оба интересны.)

Важно то, что это карта: что-то, в чем вы смотрите. Остальное - это деталь реализации.

Я бы предложил дать ему семантическое имя, например,

Map<String, Object> nameToSessionMap = ...

... таким образом, когда вы будете читать код, вы будете знать, какими должны быть ключи и значения.

Что касается типа переменной - опять же, я бы обычно использовал интерфейс, а не реализацию частично, потому что это указывает на то, что я не использую какие-либо элементы, специфичные для типа. Я не хочу подчеркивать реализацию в коде, обычно ... это означает, что когда я занимаюсь заботой о реализации, я могу сделать это более очевидным.

6 голосов
/ 19 августа 2010

Объявление объекта как Map позволит компилятору защитить вас от вызова методов, специфичных для HashMap. Это позволит вам в будущем заменить другую реализацию Map, не беспокоясь о вызовах методов, которых нет в интерфейсе Map.

1 голос
/ 19 августа 2010

Даже в этом случае он сохраняет его универсальным. Кодирование интерфейса гарантирует, что вы используете Map, а не конкретную его реализацию.

1 голос
/ 19 августа 2010

Обычно люди используют в основном Map, чтобы сделать наименьшее количество предположений относительно реализации.

Не может быть, чтобы имя класса использовалось для дополнительных методов, поскольку только HashMap добавляет clone (), который вышел из употребления (по уважительным причинам).

Возможно, карта должна быть сериализуемой по той или иной причине, и интерфейс простой карты не расширяет ее, но HashMap реализует ее.

...