Comments 36
Я полностью удалила ограничения, так как мы решили добавить их позже, используя отдельные методы.
Я также использовала константы для статуса активности скидки.
А Олег то не так прост, как кажется (:
Теперь сравните это с первоначальным вызовом. Вы увидите, насколько удобнее стало читать.
Читать-то стало удобнее, но вместо одного (возможно, атомарного) вызова функции теперь нужно делать два. И при всем при этом из сигнатур функций по-прежнему не очевидно, в каких случаях надо отдельно задавать констрейнты, в каких — достаточно обойтись тем, что задается по умолчанию. Плюс если кто-то где-то забудет задать констрейнт после задания скидки, то найти багу будет непросто.
Анна изобрела рефакторинг?
Не пугайте так! А то ещё чуть-чуть и они ALGOL68 изобретут, наконец.
/**
* Это была функция из самодокументированного кода переданного нам очень давно.
* PS. HACK: Не трогать!!!!!!!!!!! Кривой код.
* @param {any} a - Тип скидки
* @param {any} b - Тип клиента, IClient.CORP | IClient.INDIVIDUAL
* @param {any} c - Фаза луны
* @param {any} d - Непонятно что, но НУЖНО ставить null
* @param {any} e - тип валюты, блин этот чувак точно был больной
*/
function SelfDocumentedFunction(a,b,c,d,e) {
....
}
Каждый божий раз, когда вижу "ироничные коменты" в коммите, вместо банального рефакторинга сигнатуры или заведённой таски на проблему, думаю какая всё-таки инфантильная индустрия. Всякое бывает, но здесь например явная опасная проблема и комент пригодится уже только после того как жахнет и пойдет разбор почему жахнуло.
так много «Я»
Хорошо у нас в свифте. Есть опшнлы, и сам язык заставляет больше думать об обработке всех значений, особенно null/не null (nil только у нас).
Помню, спорил много лет назад, «опытные» (TM) программисты говорили, что язык должен позволять все, а я профессионал такого высокого класса, а С++ (например) — язык для профессионалов, что мне можно доверять. Ошибки делают все, и каждый день, если конечно что-то делают, и лучше какие-то наши ошибки пофиксит компилятор, а язык будет от них максимально оберегать, чем ситуации, описанные в статье
Помню, спорил много лет назад, «опытные» (TM) программисты говорили, что язык должен позволять все, а я профессионал такого высокого класса, а С++ (например) — язык для профессионалов, что мне можно доверять. Ошибки делают все, и каждый день, если конечно что-то делают, и лучше какие-то наши ошибки пофиксит компилятор, а язык будет от них максимально оберегать, чем ситуации, описанные в статье
Если выбирать между инструментом, которым можно сделать абсолютно всё, но он опасен для детей и им можно прострелить ногу и инструментом, который позволяет сделать лишь часть действий я выберу первое (естественно, если действие будет удобнее/быстрее делать первым).
Тут уже дело некоторого «риска» в угоду максимальной мощности и управляемости.
Тут уже дело некоторого «риска» в угоду максимальной мощности и управляемости.
В Ruby удобно — у каждого типа свой нулевой объект ('', [], {}, 0 и т.д.)
Пустой объект (строка длиной 0, массив без элементов) != null
Я к тому, что в ruby не нужен null
Отсутствие массива и пустой массив — это, мягко говоря, совершенно разные вещи семантически.
Все, что вы описали (пустые массивы, 0 и т.д.), есть везде и эти значения можно использовать вместо null. По сути дела это null-объекты, у которых ограниченная сфера применения. Только иногда нужно сообщить, что массив неинициализирован совсем, а не то, что он пустой.
Все, что вы описали (пустые массивы, 0 и т.д.), есть везде и эти значения можно использовать вместо null. По сути дела это null-объекты, у которых ограниченная сфера применения. Только иногда нужно сообщить, что массив неинициализирован совсем, а не то, что он пустой.
В каких реальных ситуациях нужно сообщить, что массив не инициализирован совсем? Мне действительно интересно, так как не сталкивался.
Ну например при кэшировании или ленивой загрузке: пустой массив — это корректное значение, полученное откуда-то (из базы данных), а null — это указатель на то, что значение еще не запрашивали вовсе.
При этом в базе данных тоже может быть NULL, так что может потребоваться ещё и «настоящий null» и «NULL из базы данных» иногда…
Чистая правда
в этом плане, как бы смешно это не звучало, мне нравится javascript. там есть `null` и `undefined`. очень удобноо как раз использовать в семантике «получено пустое значение» и «значение еще не было проинициализировано», особенно при работе api
Ну дык Эйх (который Брендан) изначально вообще в браузер Scheme хотел затащить. Откуда он и спёр идейку (изуродовав, как обычно, «чтобы людей не пугать»). И Null/Undefined в Java. И None/False в Python. И всё прочее в этом духе обобщается в Lisp-подобных языках до понятия символа — выделенного значение. По умолчанию обычно бывают доступны #nil и #true/#false, но можно завести и какой-нибудь #database-connection-lost, если нужно…
JavaScript (и Python) «подобрали» эту идею с несколькими встроенными символами, но до того, чтобы дать возможность разработчику их создавать… «недоросли»…
JavaScript (и Python) «подобрали» эту идею с несколькими встроенными символами, но до того, чтобы дать возможность разработчику их создавать… «недоросли»…
null это просто абстракция. Invalid pointer. Даже на С можно писать без использования null. Просто его придумали во времена, когда одного invalid pointer a хватало всем ;)
Проблема не в null, а в том, что мы не видим имен аргументов. В последнем варианте можно так же спросить про строки, не видно же что каждая значит. Нагляднее (и более гибким) был бы такой вариант:
insertDiscount(new Discount()
.setName('Discount name')
.setDescription('Discount description')
.setAmount(100, 'CAD')
.setActive()
)
В этом коде все аргументы не обязательны. В исходном коде все наоборот.
То же самое хотел написать — в «лучших домах» советуют не оставлять объекты недоинициализированными, и при необходимости юзать Builder, а тут все по новой — сначала инициализируем обязательные, а потом возможно остальные. Следующая статья видимо будет про криворуких разработчиков, которые исправили(скопировали, отрефакторили) только конструктор и забыли про дополнительные сеттеры.
Наглядный вариант, как сделать возможность создать невалидное состояние обьекта и нарушить инапсуляцию
m.habr.com/ru/post/469323
m.habr.com/ru/post/469323
В соседней ветке куча людей обсуждает функциональное программирование, может тут есть кто из них. Как все это будет выглядеть в ФП?
Так эта, товарисч dead_man, как раз стиле ФП и написал
Там описана просто цепочка сеттеров (fluent interface). Это паттерн из мира ООП, ФП вообще не при чем. Не вводите людей в заблуждение.
psalm, phpstan, phan… inspect в шторме наконец.
Но нет, люди продолжают придумывать себе проблемы) на что только не пойдёшь лишь бы не работать
Assert::that($amountInCents)->greaterThan(0);Странно, что это называется assert. Это же precondition. Либо библиотека писалась для ассертов, но используется для прекондишнов. Технически разница может невелика, но семантика у ассерта и прекондишна разная.
Ассерт никак не связан с тем используют его в пред- или постусловии. Это просто проверка некоторого утверждения. В пыхе в принципе даже родной ассерт есть
www.php.net/manual/ru/function.assert.php
www.php.net/manual/ru/function.assert.php
Sign up to leave a comment.
«Нулевой» ад и как из него выбраться