Но в видео, на которое вы ссылаетесь, человек как раз говорит, что это подавление работает только в комнате без отражения звука (он демонстрирует в гардеробе, забитом одеждой). И только в той точке, где стоит камера. А вдруг точках звук наоборот усиливается
Я вот тоже не очень понял эту формулировку в статье. Разве "ядерный распад" - это не распад, собственно, ядра? С образованием элементов с меньшими атомными номерами, а не с большим
То есть эффективность использования программистов резко возрастает. Экономисты говорят нам, что в случае увеличения эффективности использования ресурса спрос на него растет (см парадокс Джевонса)
Согласен, симпатичнее. Но между этими оверкиллами есть и промежуточные решения.
У меня вообще нет никаких вопросов к Бёму. Наверняка он получил кучу фана от процесса. Я, возможно, тоже на его месте так закопался бы (если бы умел делать это так же круто, как он).
Мне скорее интересна точка зрения его условного менеджера, у которого суперстар девелопер месяц пилит калькулятор для андроида, чтобы в нем можно было поделить Пи на корень из е с произвольной точностью. Как он обосновывает эти затраты.
Еще когда читал статью в оригинале, задумался над вопросм "А зачем это нужно было гуглу?". В чем смысл стрелять из пушки по воробьям, тратя дорогущее время топового специалиста (который потом вовлек еще двоих такого же уровня) на калькулятор, который 99% пользователей используют чтобы поделить чек в кафе? Ну, допустим, есть еще школьники с чуть более сложными вычислениями. Но все равно кажется, что описанное выше - это чудовищный оверкилл.
"Никто не заметит если я сделаю плохо" - вообще довольно странное основание чтобы делать плохо
Просто "плохо" - очень субъективное слово, которое вы с коллегой могли понимать по разному. Он же тоже руководствовался некой целессобразностью, когда этот код писал.
Контекст вашего примера мне неизвестен, поэтому конкретную ценность переписывания с квадрата на логарифм я оценить не могу. Если это какой-то бэкенд код, перемалывающий данные и потецниально подлежащий масштабированию, то честь вам и хвала за такое ревью, вы помогли устранить углы в будущем. Если же это формирование элементов для показа пользователю в UI (которых ну максимум несколько десятков может быть), то тут дело другое. В таком коде критерии "так читается понятнее" и даже "так было быстрее реализовать" имеют куда больший вес в оценке "хорошо/плохо сделано". А требования переписать такой код на logN будут отдавать скорее карго-культом.
Так он же сам и объяснил почему так произошло. Договор действительно может быть признан ущемляющим интересы одной из сторон, если его содержание примерно описывается как "Все имущество одному супругу. Второго - с голой ж*** на мороз".
И это, если вдуматься, логично. Для любого договора, не только брачного. Действительно странно предположить, что две стороны добровольно без давления договорились, что все профиты получит одна сторона, а второй - 0.
Так-то и договоры дарения недвижимости, бывает, оспаривают по этой же причине
Странно, что автор не упомянул в качестве маховика, разгоняющего "инфляцию должностей", компании-бодишопы (aka галеры). Потому что там назвать всех сеньорами и продавать их заказчикам подороже - это буквально бизнес-модель кампании.
с Null-object мы снимаем с разработчика дополнительную логику и реализовываем сами
Боюсь, эта абстракция очень быстро начинает подтекать в реальных юзкейсах. Например, нам дают List<String> из айдишников книг и просят показать список из этих книг, отсортированный по тому же количеству станиц. Или, скажем, сгрупированный по автору. И вот мне уже нужно знать, что книга из метода getBook() прилетает не всегда настоящая.
Не нужно вам возвращать null из метода, уж поверьте. Не мне так популярным фреймворкам, где это применяют.
Это вопрос требований и реализации логики. Где то уместно вывести имя "Unknown" и ничего не делать при "Отправить письмо" , а где то - нет.
Со всем уважением, но я с трудом представляю требование показывать пользователю технический объект-заглушку там, где на самом деле объекта нет.
Nullable подойдет, чтобы пометить поле в объекте.
А чем плохо помечать Nullable метод?
Nullable работает только в compile time.
Так если мы говорим о способе избегать NPE, то есть по сути о борьбе с человеческими ошибками, то compile time вполне достаточно. Ну Optional будет более строгим, да. Но ценой читабельности кода.
Еще раз уточню с чем я спорю. Я согласен с посылом, что можно использовать Optional для возвращения потенциально null значений (если не пугает объем кода). Я также не вижу проблемы в использовании Null-object для определенных кейсов. Мне показалось излишне строгим предложение никогда не возвращать null из методов. Потому что я не вижу в этом ничего плохого, если при этом не забывать помечать метод соответствующей аннотацией.
"более сложный" пример как раз хорошо объясняет то, что я имел в виду. Если не использовать проверки, то в каком-то интерфейсе вашего продукта у вас всплывет фейковый друг с именем "Unknown" и кнопкой "Отправить письмо", которая ничего не делает. Хотя логичнее было бы увидеть сообщение "Друг не задан, выберите друга".
Я не говорю, что Null-object антипаттерн. Он полезен в специфических случаях. Но как универсальную замену null-ов я бы его не советовал. Правило "всегда использовать использовать аннотации @Nullableтам, где может прилететь null" выглядит проще и безопаснее
А чем Null-Object удобнее в обработке, чем простой null? Если каждый раз писать проверку вида
if (value != NULL_VALUE) ...
то разницы вроде и никакой. Только этот NULL_VALUE надо еще для каждого класса задефайнить и где-то в глобальной переменной держать. А null из коробки есть. И инспекции в IDE опять же с null подскажут, что я проверку упустил, а с NULL_VALUE - уже нет.
А ежели проверки не писать, то это будет источником багов, которые отлавливаются куда хуже, чем NPE. NPE хотя бы fail fast.
Optional да, лучше. Но выше уже отвечал, что он уж больно код раздувает. Хотя это вкусовщина, возможно
Для ребенка трех-четырех лет неплохо было бы сначала определить операцию сложения. Иначе почему он должен угадывать, что мы считаем правильным ответ "пять предметов", а не "арбузно-апельсиновый смузи" или "натюрморт".
На мой вкус Optional ужасно раздувает и делает плохочитаемым код. А уж если у вас больше одной nullable переменной, то замена строки if (a != null && b != null) {} на альтернативу с Optional будет выглядеть как небольшая программа на Лиспе
Мой вопрос не к тому, что нужно искать какую-то другую "серебряную пулю". Я скорее к тому, что не стоит так уж демонизировать null. Вполне нормальная практика его возвращать, когда это уместно, как по мне. Аннотации @Nullable/@NotNull и ворнинги в IDE решают почти все потенциальные проблемы с использованием null.
Optional спасает и от NPE в цеплочке вида country.getCity().getDistrict().getStreet().getHouse().getApartment()
В такого рода вызовах Optional - то, что надо, да.
Но в видео, на которое вы ссылаетесь, человек как раз говорит, что это подавление работает только в комнате без отражения звука (он демонстрирует в гардеробе, забитом одеждой). И только в той точке, где стоит камера. А вдруг точках звук наоборот усиливается
Я вот тоже не очень понял эту формулировку в статье. Разве "ядерный распад" - это не распад, собственно, ядра? С образованием элементов с меньшими атомными номерами, а не с большим
То есть эффективность использования программистов резко возрастает. Экономисты говорят нам, что в случае увеличения эффективности использования ресурса спрос на него растет (см парадокс Джевонса)
Возможно, им просто нужно было как-то считать долг перед российскими телеканалами )))
Согласен, симпатичнее. Но между этими оверкиллами есть и промежуточные решения.
У меня вообще нет никаких вопросов к Бёму. Наверняка он получил кучу фана от процесса. Я, возможно, тоже на его месте так закопался бы (если бы умел делать это так же круто, как он).
Мне скорее интересна точка зрения его условного менеджера, у которого суперстар девелопер месяц пилит калькулятор для андроида, чтобы в нем можно было поделить Пи на корень из е с произвольной точностью. Как он обосновывает эти затраты.
Это само собой! С точки зрения примера как основательно человек решал задачу, история максимально впечатляющая.
Еще когда читал статью в оригинале, задумался над вопросм "А зачем это нужно было гуглу?". В чем смысл стрелять из пушки по воробьям, тратя дорогущее время топового специалиста (который потом вовлек еще двоих такого же уровня) на калькулятор, который 99% пользователей используют чтобы поделить чек в кафе?
Ну, допустим, есть еще школьники с чуть более сложными вычислениями. Но все равно кажется, что описанное выше - это чудовищный оверкилл.
Просто "плохо" - очень субъективное слово, которое вы с коллегой могли понимать по разному. Он же тоже руководствовался некой целессобразностью, когда этот код писал.
Контекст вашего примера мне неизвестен, поэтому конкретную ценность переписывания с квадрата на логарифм я оценить не могу. Если это какой-то бэкенд код, перемалывающий данные и потецниально подлежащий масштабированию, то честь вам и хвала за такое ревью, вы помогли устранить углы в будущем. Если же это формирование элементов для показа пользователю в UI (которых ну максимум несколько десятков может быть), то тут дело другое. В таком коде критерии "так читается понятнее" и даже "так было быстрее реализовать" имеют куда больший вес в оценке "хорошо/плохо сделано". А требования переписать такой код на logN будут отдавать скорее карго-культом.
...То вы все равно не должны ей ничего с этого холдинга. Банк - самостоятельно юрлицо, его имущество к вам никакого отношения не имеет
Так он же сам и объяснил почему так произошло. Договор действительно может быть признан ущемляющим интересы одной из сторон, если его содержание примерно описывается как "Все имущество одному супругу. Второго - с голой ж*** на мороз".
И это, если вдуматься, логично. Для любого договора, не только брачного. Действительно странно предположить, что две стороны добровольно без давления договорились, что все профиты получит одна сторона, а второй - 0.
Так-то и договоры дарения недвижимости, бывает, оспаривают по этой же причине
Странно, что автор не упомянул в качестве маховика, разгоняющего "инфляцию должностей", компании-бодишопы (aka галеры). Потому что там назвать всех сеньорами и продавать их заказчикам подороже - это буквально бизнес-модель кампании.
Кстати, спасибо за развернутые ответы с примерами! Понимаю, что на это нужно много времени, и очень ценю )))
Боюсь, эта абстракция очень быстро начинает подтекать в реальных юзкейсах. Например, нам дают
List<String>из айдишников книг и просят показать список из этих книг, отсортированный по тому же количеству станиц. Или, скажем, сгрупированный по автору. И вот мне уже нужно знать, что книга из методаgetBook()прилетает не всегда настоящая.Ну уж слишком-то сильно не обобщайте, только ситхи всё возводят в абсолют ))))
навскидку надергал примеров из Hibernate:
https://docs.jboss.org/hibernate/orm/6.6/javadocs/org/hibernate/boot/ResourceLocator.html#locateResource(java.lang.String)
https://docs.jboss.org/hibernate/orm/6.6/javadocs/org/hibernate/SharedSessionContract.html#getTenantIdentifier()
https://docs.jboss.org/hibernate/orm/6.6/javadocs/org/hibernate/SharedSessionContract.html#getEntityGraph(java.lang.String)
из RxJava:
https://reactivex.io/RxJava/javadoc/
и Jackson:
https://www.javadoc.io/static/com.fasterxml.jackson.core/jackson-core/2.18.0/com/fasterxml/jackson/core/io/CharacterEscapes.html#getEscapeSequence-int-
Весьма популярные.И вполне возвращают, там где это уместно. Философии фреймворков они разные бывают )))
Со всем уважением, но я с трудом представляю требование показывать пользователю технический объект-заглушку там, где на самом деле объекта нет.
А чем плохо помечать
Nullableметод?Так если мы говорим о способе избегать NPE, то есть по сути о борьбе с человеческими ошибками, то compile time вполне достаточно. Ну
Optionalбудет более строгим, да. Но ценой читабельности кода.Еще раз уточню с чем я спорю. Я согласен с посылом, что можно использовать
Optionalдля возвращения потенциальноnullзначений (если не пугает объем кода). Я также не вижу проблемы в использовании Null-object для определенных кейсов. Мне показалось излишне строгим предложение никогда не возвращатьnullиз методов. Потому что я не вижу в этом ничего плохого, если при этом не забывать помечать метод соответствующей аннотацией.del
"более сложный" пример как раз хорошо объясняет то, что я имел в виду. Если не использовать проверки, то в каком-то интерфейсе вашего продукта у вас всплывет фейковый друг с именем "Unknown" и кнопкой "Отправить письмо", которая ничего не делает. Хотя логичнее было бы увидеть сообщение "Друг не задан, выберите друга".
Я не говорю, что Null-object антипаттерн. Он полезен в специфических случаях. Но как универсальную замену null-ов я бы его не советовал. Правило "всегда использовать использовать аннотации
@Nullableтам, где может прилететь null" выглядит проще и безопаснееА чем Null-Object удобнее в обработке, чем простой null? Если каждый раз писать проверку вида
то разницы вроде и никакой. Только этот NULL_VALUE надо еще для каждого класса задефайнить и где-то в глобальной переменной держать. А null из коробки есть. И инспекции в IDE опять же с null подскажут, что я проверку упустил, а с NULL_VALUE - уже нет.
А ежели проверки не писать, то это будет источником багов, которые отлавливаются куда хуже, чем NPE. NPE хотя бы fail fast.
Optional да, лучше. Но выше уже отвечал, что он уж больно код раздувает. Хотя это вкусовщина, возможно
Для ребенка трех-четырех лет неплохо было бы сначала определить операцию сложения. Иначе почему он должен угадывать, что мы считаем правильным ответ "пять предметов", а не "арбузно-апельсиновый смузи" или "натюрморт".
На мой вкус Optional ужасно раздувает и делает плохочитаемым код. А уж если у вас больше одной nullable переменной, то замена строки
if (a != null && b != null) {}на альтернативу сOptionalбудет выглядеть как небольшая программа на ЛиспеМой вопрос не к тому, что нужно искать какую-то другую "серебряную пулю". Я скорее к тому, что не стоит так уж демонизировать null. Вполне нормальная практика его возвращать, когда это уместно, как по мне. Аннотации
@Nullable/@NotNullи ворнинги в IDE решают почти все потенциальные проблемы с использованием null.В такого рода вызовах Optional - то, что надо, да.
А что делать если null - валидное значение. Так-то null вполне естественный способ вернуть ответ "того, что ты ищешь, у меня нет"