Я и имел ввиду эту банальность: compareTo определяет порядок следования двух элементов, а equals — их равенство. Для тех же строк, в которых встречаются хитрые символы алфавита, мы получим compareTo = 0, equals = false.
Просто исходная ветка комментариев, куда я встрял с ответом, чем породил данное обсуждение, была про DAL. Вот поэтому круг примеров и сузился до Get/Find :) Я тоже не сразу это понял.
На самом деле, мы похоже что говорим о разном. Я не предлагаю из DAL возвращать Null Object. Ну его нафиг, сами разгребайте потом такой код. И пожалуйста Maybe — туда же.
Человек выше уточнил наличие принципиальной разницы между if (obj == nul) {} vs Null Object, на что я и ответил.
Для начала отвечу вопросом на вопрос: а зачем? Я клоню к тому, что в каких-то случаях мне важно, вернули ли мне существующий объект, в каких-то — будет достаточно и «пустышки». Там, где существование важно, от проверки типа obj != null / obj.HasValue / obj is NullObject не уйти. Где не важно — есть способ избавиться от разбросанных по коду if (obj == null ) { /* special case */ } и собрать их в единственном месте.
Но принимать ответственность за принятие данного решения лежит исключительно на мне, как авторе клиентского кода. Вызываемого мною метода не должен касаться контекст его выполнения.
Я не очень понял суть вашего комментария. Придумайте другой пример, если не понравилось «ФИО по-умолчанию». Сути то это не поменяет: используя означенный паттерн, мы собираем в одном месте поведение системы в случаях, когда входной объект — null. (Для того же объекта «пользователь» это ещё и сброшенный флаг активности, пустой список назначенных ролей и т.д.)
Разница на самом деле есть. Используя данный паттерн, вы собираете в одном месте разбросанные по проекту куски кода а-ля if (document.ResponsibleUser == null) {… }. У null-пользователя будут заполненные значением по-умолчанию ФИО, логин, список ролей и т.д.
Как ещё один вариант: паттерн special case. Фаулер обычно дело говорит. Если репозиторий может вернуть NULL вместо пользователя, то пусть это (в некоторых случаях) будет NullUser.
Я тоже противник подобных «олимпиадных» задач на собеседованиях — действительно, они не выявляют наличие или отсутствие скиллов хорошего разработчика.
Однако мне кажется на данный вопрос нужно взглянуть с другой стороны: а почему Twitter задаёт такие задачи? Может быть, они ищут не очередного фронт-ендщика, а кого-то другого. Может быть, кандидат будет работать в области, где нужно решать по какому алгоритму распределять пользователей по серверам БД, опираясь на специфику нагрузки именно на twitter.com. И при их объёмах, разница во времени обработки запроса в жалкие 10 мс — критична в плане нагрузки на CPU. Среднестатистический веб-разработчик, имеющий опыт работы с кучей систем контроля версий, умеющий верстать с закрытыми глазами, имеющий опыт построения сложных enterprise-систем, гуру ООП и декомпозиции — не выжмет эти 10 мс. «Олимпиадник» — возможно (хотя бы, сэкономив на кол-ве вызовов функций во время работы данного алгоритма, игнорируя SRP, абстракции и превратив код в трудновоспринимаемую лапшу).
А может быть они и просто выкаблучиваются на ровном месте, т.к. поток собеседований бесконечен и тратить по 2 часа на очередного кандидата слишком неэффективно :))
При первом вызове объект помечается как мусорный и после уборки, в фоне вызывается его финализатор. Как результат, объект остаётся в памяти. При втором вызове, объект будет окончательно удалён. Если финализатор успел вызваться :) По-хорошему, между обоими вызовами необходимо вставить GC.WaitForPendingFinalizers()
Однако, два раза подряд вызывать полную уборку мусора и грузить CPU ради одного финализатора — негуманно. Для аналогичного поведения лучше использовать другие механизмы.
На всякий случай: martinfowler.com/eaaCatalog/specialCase.html
На самом деле, мы похоже что говорим о разном. Я не предлагаю из DAL возвращать Null Object. Ну его нафиг, сами разгребайте потом такой код. И пожалуйста Maybe — туда же.
Человек выше уточнил наличие принципиальной разницы между if (obj == nul) {} vs Null Object, на что я и ответил.
Но принимать ответственность за принятие данного решения лежит исключительно на мне, как авторе клиентского кода. Вызываемого мною метода не должен касаться контекст его выполнения.
Однако мне кажется на данный вопрос нужно взглянуть с другой стороны: а почему Twitter задаёт такие задачи? Может быть, они ищут не очередного фронт-ендщика, а кого-то другого. Может быть, кандидат будет работать в области, где нужно решать по какому алгоритму распределять пользователей по серверам БД, опираясь на специфику нагрузки именно на twitter.com. И при их объёмах, разница во времени обработки запроса в жалкие 10 мс — критична в плане нагрузки на CPU. Среднестатистический веб-разработчик, имеющий опыт работы с кучей систем контроля версий, умеющий верстать с закрытыми глазами, имеющий опыт построения сложных enterprise-систем, гуру ООП и декомпозиции — не выжмет эти 10 мс. «Олимпиадник» — возможно (хотя бы, сэкономив на кол-ве вызовов функций во время работы данного алгоритма, игнорируя SRP, абстракции и превратив код в трудновоспринимаемую лапшу).
А может быть они и просто выкаблучиваются на ровном месте, т.к. поток собеседований бесконечен и тратить по 2 часа на очередного кандидата слишком неэффективно :))
Но да, за последние много лет такое впервые.
Однако, два раза подряд вызывать полную уборку мусора и грузить CPU ради одного финализатора — негуманно. Для аналогичного поведения лучше использовать другие механизмы.