Использовать HashMap для хранения переменных экземпляра?

#java #hashmap

#java #hashmap

Вопрос:

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

То, что я придумал, — это использовать HashMap для хранения пар ключ / значение для объекта, а затем предоставлять эти значения с помощью метода get и set .

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

 package ocaff;

import java.util.HashMap;

public class OcaffObject {

    private HashMap<String, Object> data;

    public OcaffObject() {
        this.data = new HashMap<String, Object>();
    }

    public Object get(String value) {
        return this.data.get(value);
    }

    public void set(String key, Object value) {
        this.data.put(key, value);
    }

}
  

Хотя функционально это работает, мне любопытно, есть ли какие-либо реальные проблемы с этой реализацией или есть лучший способ сделать это?

В своей повседневной работе я программист на PHP, и моей целью было имитировать функциональность, которую я использовал в PHP, в Java.

Комментарии:

1. Вы могли бы это сделать, но зачем? Если вы хотите передать хэш-карту, просто передайте хэш-карту. ИМО, вы теряете преимущества, если многое из того, что представляет собой ООП, если вы просто бросаете все на карту.

Ответ №1:

Я не думаю, что это хороший способ разобраться с тем, что вы имеете в виду. С моей точки зрения, программирование на java сильно отличается от программирования на php.

Вам нужно поддерживать чистоту и строгую типизацию, используя реальную парадигму чистого объектно-ориентированного программирования.

Мне приходят в голову некоторые проблемы с этой техникой, вот некоторые, не в порядке важности.

  1. Первая проблема, с которой вы сталкиваетесь, — это производительность и объем памяти: это будет потреблять много памяти и будет работать очень плохо.

  2. Вторая проблема — параллелизм, HashMap не является потокобезопасным.

  3. Третья проблема — безопасность типов: у вас больше нет безопасности типов, вы можете записывать в поле все, что хотите, и никто это не проверяет, настоящий анти-шаблон.

  4. Четвертая проблема — отладка… отлаживать ваш код будет сложно.

  5. Пятая проблема: каждый может писать и читать любое поле, зная его имя.

  6. Шестая проблема: когда вы меняете имя поля в хэш-наборе, вы не получаете никакой ошибки во время компиляции, вы получаете только странное поведение во время выполнения. Рефакторинг станет невозможным.

Типизированные поля гораздо более полезны и понятны.

Комментарии:

1. 1 Мне нравится ваш список проблем. Я особенно считаю, что 3, 4, 5 и 6 важнее, чем 1 и 2, но даже об этих 2 важно знать.

2. Да, согласен, последние пункты важнее 🙂 но производительность может быть проблемой, когда это базовый класс для класса User, например, и у вас 1000000 пользователей в Сети 🙂 lol 🙂

3. Это именно тот тип информации, который я искал. Я рад, что спросил, прежде чем я зашел слишком далеко в своем проекте. Спасибо.

4. Для меня … спорить о том, какой из этих пунктов важнее, все равно что спорить о том, что важнее для автомобиля — наличие протектора на шинах или бензина в баке. Это вопрос перспективы.

Ответ №2:

Если вы тратите время на создание класса для этого, я бы просто добавил то, что вам нужно, в качестве членов класса. Это даст вам возможность проверять членов вашего класса во время компиляции, что значительно уменьшит количество мелких ошибок.