Там какой-либо недостаток к возврату этого вместо пустоты?
NullPointerException s - исключения, возникающие при попытке использовать ссылку, которая указывает на отсутствие местоположения в памяти (null), как если бы она ссылалась на объект. Вызов метода по нулевой ссылке или попытка получить доступ к полю нулевой ссылки вызовет функцию NullPointerException. Они наиболее распространены, но другие способы перечислены на странице NullPointerException javadoc.
Вероятно, самый быстрый пример кода, который я мог бы придумать для иллюстрации NullPointerException, be:
public class Example {
public static void main(String[] args) {
Object obj = null;
obj.hashCode();
}
}
В первой строке внутри main я явно устанавливаю ссылку Object obj равной null. Это означает, что у меня есть ссылка, но она не указывает на какой-либо объект. После этого я пытаюсь обработать ссылку так, как если бы она указывала на объект, вызывая метод на нем. Это приводит к NullPointerException, потому что нет кода для выполнения в местоположении, на которое указывает ссылка.
(Это техничность, но я думаю, что она упоминает: ссылка, которая указывает на null, равна 't то же, что и указатель C, указывающий на недопустимую ячейку памяти. Нулевой указатель буквально не указывает на в любом месте , который отличается от указаний на местоположение, которое оказывается недопустимым.)
7 ответов
Я знаю в Java, они на самом деле думают о создании этого стандартного поведения для пустых методов. Если Вы делаете это, Вам не нужен дополнительный синтаксический сахар.
Единственный недостаток, о котором я могу думать, является производительностью. Но это легко измеряется. Я возвращусь к Вам с результатами через несколько минут :-)
Править:
Возврат ссылки немного медленнее, чем возврат пусто..какой сюрприз. Таким образом, это - единственный недостаток. Еще несколько галочек при вызывании функции.
Я думаю как общая политика, она просто не имеет смысла. Объединение в цепочку метода этим способом работает с правильно определенным интерфейсом, но только уместно, если это имеет семантический смысл.
Вашим примером является главный, где это не является соответствующим, потому что он не имеет никакого семантического смысла.
Точно так же Ваш синтаксический сахар является ненужным с правильно разработанным быстрым интерфейсом.
Быстрые интерфейсы или объединение в цепочку метода могут работать очень хорошо, но должны быть разработаны тщательно.
Разве это не то, как "быстрые интерфейсы" - как те, которых JQuery использует - создаются? Одно преимущество, как предполагается, является удобочитаемостью кода (хотя статья в Википедии по http://en.wikipedia.org/wiki/Fluent_interface упоминает, что некоторые находят его НЕ читаемым). Другое преимущество находится в краткости кода, Вы теряете потребность установить свойства в 7 строках кода и затем назвать метод на том объекте в 8-й строке.
Martin Fowler (кто ввел термин здесь - http://martinfowler.com/bliki/FluentInterface.html) говорит, что существует больше к быстрым интерфейсам, чем объединение в цепочку метода, однако объединение в цепочку метода является общей техникой для использования с быстрыми интерфейсами.
Править: Я на самом деле возвращался сюда, чтобы отредактировать мой ответ и добавить, что нет никакого недостатка к возврату этого вместо пустоты никаким измеримым способом, когда я видел, что комментарий George указал, что я действительно забывал обсуждать момент вопроса. Извините за начальное "бессмысленное" быстрое движение.
При возврате "сам" или "это" - общий шаблон, иногда называемый "объединением в цепочку метода". Что касается Вашего предложенного сахара синтаксиса, я не так уверен. Я не парень.NET, но это не кажется ужасно полезным для меня.
Платформа Objective C NeXTSTEP раньше использовала этот шаблон. Это было прекращено в той платформе, однажды распределил объекты (вызовы удаленной процедуры, в основном) были добавлены к языку — функция, которая возвратилась self должен был быть синхронный вызов, так как распределенная объектная система видела тип возврата и предположила, что вызывающая сторона должна будет знать результат функции.
Единственный недостаток, который я вижу, - то, что это делает API немного более сбивающим с толку. Скажем, у Вас есть некоторый объект коллекции с удалением () метод, который обычно возвращался бы пусто. Теперь Вы хотите возвратить ссылку на сам набор. Новая подпись была бы похожа:
public MyCollection remove(Object someElement)
Просто смотря на подпись, не ясно, что Вы возвращаете ссылку на тот же экземпляр. Возможно, MyCollection неизменен, и Вы возвращаете новый экземпляр. В некоторых случаях, как здесь, Вам была бы нужна некоторая внешняя документация для разъяснения этого.
Мне на самом деле нравится эта идея, и я полагаю, что был некоторый разговор в модифицировании всех пустых методов в Java7 для возврата ссылки на 'это', но это в конечном счете провалилось.
На первый взгляд это может выглядеть хорошим, но для последовательного интерфейса Вам будет нужен тот весь, методы возвращают ссылку на это (который имеет его собственные проблемы).
Позвольте говорят, что у Вас есть класс с двумя методами GetA, которые возвращают это и GetB, которые возвращают другой объект:
Затем можно назвать obj. GetA ().GetB (), но не obj. GetB ().GetA (), который, по крайней мере, не делает, кажется последовательным.
С Паскалем (и Visual Basic) можно назвать несколько методов того же объекта.
with obj .GetA(); .GetB(); end with;
Проблема с этой функцией состоит в том, что легко можно написать код, который более трудно понять, чем это должно быть. Также добавление нового оператора, вероятно, делает его еще тяжелее.