Который является 'корректным' способом сделать это (если оператор)
У меня есть многие из них лежащих вокруг, и я задаюсь вопросом, собираюсь ли я столкнуться с проблемой - или проблемы производительности.
У меня есть метод A:
MyClass monkey;
...
if(monkey != null) {
...
}
Или метод B:
boolean hasMonkey; //This is set to TRUE when monkey is not null
MyClass monkey;
...
if(hasMonkey) {
...
}
На функциональном уровне они оба делают то же самое. Прямо сейчас я использую метод A. Это - плохой способ сделать вещи? Который собирается работать лучше?
8 ответов
Метод A - это то, что я видел как "обычный" случай. Метод B создает проблему согласованности данных (что если hasMonkey не будет установлен правильно?), в то время как метод A полагается только на сам объект для определения его валидности. На мой взгляд, метод A намного лучше.
Нет ничего плохого в методе A, IMO. Метод B является своего рода нарушением принципа DRY (как я его вижу) - установка и проверка флага, указывающего, является ли ссылка monkey нулевой, является дублированием / избыточностью.
Я не думаю, что любой подход может повлиять на производительность, поскольку вы тестируете условие в обоих случаях.
Определенно метод A. Если вы хотите протестировать обезьяну против null , просто сделайте это. Зачем вам нужна дополнительная переменная? Кто следит за правильной настройкой? Больше головной боли, больше ошибок, никакой выгоды.
В общем, я бы выбрал A - более ясный, простой и последовательный.
Но, если это замкнутая петля, вы можете попробовать второй, но всегда с профилем. Будет ли прирост производительности зависит от того, насколько умна виртуальная машина. В зависимости от реализации виртуальной машине может потребоваться проверка нулевого указателя перед использованием ссылки «обезьяна», если базовое оборудование не может использоваться для перехвата доступа к недопустимому указателю. В этом случае виртуальная машина всегда будет проверять ссылку, но она также может быть достаточно умной, чтобы выяснить, не является ли ссылка нулевой - например, если у вас есть явная проверка. Таким образом, использование A также может быть наиболее эффективным вариантом.
Метод A, безусловно, лучше, поскольку вам не нужно тратить дополнительные накладные расходы на другое логическое значение, которое потребует дополнительного места в памяти в стеке и в соответствии с вашим описанием должен оставаться в живых до области объекта Monkey.
Метод A хорош - зачем загромождать код ненужными переменными?
Метод A просто имеет больше смысла, поскольку он хранит данные в одном месте, так что вам не нужно беспокоиться о повсеместном обновлении hasMonkey.
Я бы сказал, что нужно использовать первый метод.
Проблема второго метода в том, что у вас есть избыточная информация. Возможна ситуация, когда у вас есть monkey, но hasMonkey ложно, или, возможно, хуже: согласно hasMonkey у вас есть обезьяна, но при попытке доступа к члену она выбрасывает NullPointerException. Первый метод позволяет избежать этой потенциальной проблемы.