Java: лучше нулевое значение объекта по умолчанию - PullRequest
2 голосов
/ 24 мая 2011

Первый случай: Есть класс, у которого есть другой класс в качестве члена данных. Когда создается этот класс, что мы должны делать с элементом данных?

  • (A) В конструкторе: this.anotherClass = new AnotherClass ();
  • (B) оставил его нулевым, нет необходимости создавать его экземпляр.

Второй случай: Существует класс, в котором ArrayList является элементом данных. Когда создается этот класс, что мы должны делать с ArrayList?

  • (A) В конструкторе: this.bulidingList = new ArrayList ();
  • (B) оставил его нулевым, нет необходимости создавать его экземпляр.

Третий случай: когда мы создаем метод, в котором его типом возврата является collection , например

public ArrayList getBuildingList () { /// Бах Бах Бах .. }

если здания нет, мы должны вернуть пустой ArrayList " new ArrayList () " "или null .

Ответы [ 8 ]

5 голосов
/ 24 мая 2011

Я бы предпочел не использовать нуль, чтобы избежать потенциальных NullPointerException. Чтобы избежать создания ненужных объектов, вы можете создать один статический экземпляр для возврата, если он неизменен. Что касается пустого ArrayList, вы можете использовать Collections.emptyList(), чтобы сделать это для вас.

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

2 голосов
/ 24 мая 2011

Конкретного ответа нет.Это случай вашего API или, проще говоря, ожиданий окружающего кода.

Постарайтесь подробно подумать о вашем getBuildingList ().Это нормально, чтобы вернуть ноль?Или null запрещен, и вы должны вернуть пустой список?

В любом случае, документируйте ваши мысли в javadoc для метода.

2 голосов
/ 24 мая 2011

Каковы ваши потребности? Мое общее предпочтение - возвращать ноль, когда это возможно, поскольку это позволяет избежать создания другого объекта в памяти.

При условии, что в документации четко указано, что метод может возвращать ноль, и для решения этой проблемы отвечает код, я не вижу проблемы.

1 голос
/ 24 мая 2011

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

  • Для коллекций вернуть пустую коллекцию;например, Collections.emptyList() или new ArrayList() ... в зависимости от требований API.
  • Для массивов верните массив нулевой длины.
  • Для объектов определите, возможно ли использоватьВыделенный экземпляр класса, или чтобы спроектировать API так, чтобы результат не мог быть null во-первых.

Если вам нужно вернуть null или принять null в качестве параметра метода убедитесь, что в javadoc четко указано, что это допустимый результат / аргумент ... и что это означает .


Проблема с API, которые используютnull означает, что разработчики забывают о случае null, и в результате получается NullPointerException.Можно сказать, что это не ошибка дизайнера API - пользователь API должен был прочитать документацию.Но это не решает проблему.Лучше всего избегать возврата null, особенно в тех случаях, когда есть простая альтернатива.

Другой момент заключается в том, что ненулевое значение, как правило, проще для вызывающей стороны.с.null обычно должен рассматриваться в качестве особого случая вызывающим кодом.Ненулевое значение не имеет.Например, вы можете перебирать пустую коллекцию или массив, используя цикл for, но null должен быть явно проверен.

1 голос
/ 24 мая 2011

Является ли инициализированный по умолчанию объект значимым, как, конечно, пустой ArrayList? Затем создайте его экземпляр. Не оптимизируйте преждевременно.

С другой стороны, если значение по умолчанию AnotherClass не имеет смысла, оставьте элемент пустым.

Наконец, , если вы столкнетесь с проблемами производительности или использования памяти, рассмотрите возможность пересмотра дизайна.

1 голос
/ 24 мая 2011

Учитывая деструктивную природу Null в Java, я считаю хорошей практикой возвращать пустые коллекции, а не нулевые.

Для объектов вы должны возвращать «ноль», если объект не имеет внутренних значений.

0 голосов
/ 24 мая 2011

Первый случай: существует класс, в котором в качестве члена данных используется другой класс.Когда создается этот класс, что мы должны делать с элементом данных?

(A) В конструкторе: this.anotherClass = new AnotherClass ();

(B) оставил его нулевым, нетнужно создать его экземпляр.

Я бы предпочел (C) В конструкторе: требуется ненулевой AnotherClass параметр.

Если вам нужен конструктор по умолчанию и вы всегда ожидаетеВызывающий также должен вызывать setAnotherClass(), после чего вы можете оставить его null в конструкторе и проверить на нулевое значение, когда вы фактически используете поле, в противном случае вам, вероятно, следует создать объект AnotherClass по умолчанию в конструкторе.

Второй случай: существует класс, в котором ArrayList является элементом данных.Когда создается этот класс, что мы должны делать с ArrayList?

(A) В конструкторе: this.bulidingList = new ArrayList ();(B) оставил его пустым, нет необходимости создавать его экземпляр.

Я бы всегда создавал его экземпляр, но если список доступен только для чтения, я бы объявил его таким образом:

List<Building> buildingList = Collections.emptyList();

Третий случай: когда мы создаем метод, в котором его тип возвращаемого значения является коллекцией, например

public ArrayList getBuildingList () {/// Бах Бах Бах ..}

если здания нет, мы должны вернуть пустой ArrayList "new ArrayList ()" "или ноль.

Я не особо горжусь этим,но я иногда возвращаю null, когда мне нужно дополнительное возвращаемое значение, что-то вроде getBuildingsListAndReturnNullIfThereAreNoTenants. Когда вы просто хотите сказать: «Я не нашел никаких зданий», всегда лучше вместо этого возвращать пустой список.

Иногда вы можете выполнить предварительную проверку и вернуть Collections.emptyList() вместо создания нового ArrayList<Building> экземпляра, но я бы не стал делать это изо всех сил.

0 голосов
/ 24 мая 2011

Третий случай: когда мы создаем метод, в котором его тип возвращаемого значения является коллекция, например

public ArrayList< Building > getBuildingList(){ /// Bah Bah Bah.. }

Это ужасно, открытый член никогда не должен возвращать тип реализации. Подпись должна быть:

public List< Building > getBuildingList()

Таким образом, вы можете (и должны) вернуть Collections.emptyList(), если ваши данные пусты.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...