Нормально ли в null object паттерне переопределять метод #nil?, чтобы не рефакторить все те места, где раньше возвращался nil?

Манкипатч это вообще считается дурной практикой

в реально худшем случае юзай refinements

.nil? вообще опасно трогать.

в общем атата

Нормально ли в null object паттерне переопределять метод #nil?, чтобы не рефакторить все те места, где раньше возвращался nil?

Если посмотришь гайды и гемы, то будет норм, если ты в классе (только в нем) определишь свой метод nil?

в реально худшем случае юзай refinements

Не, у меня свой класс. Раньше метод возвращал nil и во многих местах была проверка, потом поменяли на null object, но проверка на nil? осталась.

если метод собственный то не так страшно

а вот nil.nil? патчить вообще зашквар.

т.е на своем объекте проверку запилить - ну наверное можно.

Окей, спасибо!

рано или поздно лучше отрефакторить имхо

да чет хз, nullObject как раз таки вводят что бы nil? не было в коде

т.е. def nil? в nullObject всю суть nullObject’a убьет

Не, у меня свой класс. Раньше метод возвращал nil и во многих местах была проверка, потом поменяли на null object, но проверка на nil? осталась.

Кстати, посмотри на гем от авди гримма

Который для нил объектов

да чет хз, nullObject как раз таки вводят что бы nil? не было в коде

Оказывается не везде убрали, аджайл же, быстрее бы в продакшен

аджайл фигайл

потом помрете под гавнокодом.

Кстати, посмотри на гем от авди гримма

Вот еще бы он в активрекорде его везде возвращал, было бы круто

Оказывается не везде убрали, аджайл же, быстрее бы в продакшен

я не знаю что за класс, но обычно даже самый связный класс юзается с десяток раз) а это можно за 1 присест пофиксить)

если тесты есть офк

о чём трёп? чёт дохуя чиать вас

а если нет тестов, то держи вазелин —> *вазелин*

если тесты есть офк

ахахахахах

о чём трёп? чёт дохуя чиать вас

должен ли nullObject прикидываться nil’ом

а зачем nullObject вообще нужен?

а зачем nullObject вообще нужен?

Очень полезная вещь, когда объекты удаляются

Чтобы не писать везде кучу кода типа if some_object.present? some_object.blah else 'blah' end

Чтобы не писать user&.company&.name

эм

а не проще ли один раз воткнуть return unless object

Чтобы не писать везде кучу кода типа if some_object.present? some_object.blah else 'blah' end

Хотя у Авди это скорее как benign value, а не null

Чтобы не писать user&.company&.name

у тебя у нуллОбъекта нет компании. Как он имя компании получит?

ну например у тебя есть класс Животные. Есть Коши, Собаки - наследники Животные. class Cat < Animal def say “Мяу” end def count_of_lives 9 end end class Dog < Animal def say “Мяу” end def count_of_lives 1 end end И есть у тебя кусок кода, который пытается типа def foo(animal) if animal.count_of_lives > 5 do puts “IA ZIVY DOLGO” else puts animal.say end end И что бы не писать везде if.present? unless.nil? ты можешь заимплементить класс NullAnimal который имеет такой же интерфейс, как и настоящие животные

а не проще ли один раз воткнуть return unless object

Ну мб там не return надо.

и твой foo будет рабочим всегда

ну такое. Все равно надо везде учитывать что может быть нулльОбъект

ну ты по сути просто все вот эти ифы вытаскиваешь в отдельный класс и все

ну ты по сути просто все вот эти ифы вытаскиваешь в отдельный класс и все

высокая связность? :)

ну такое. Все равно надо везде учитывать что может быть нулльОбъект

Наоборот использующий код не знает, что бывает null-объект, ему пофиг. А вот null-объект должен учитывать, где он используется, ну зависит от ситуации.

вот использующий код не знает, и добавит nullObject в отчет, как существующий

высокая связность? :)

ну хз, помоему это просто чрезмерная абстракция

в яве какой-нибудь это имеет смысл, а в руби мы можем просто все заменить на нилы и поставить проверку нилов

в яве какой-нибудь это имеет смысл, а в руби мы можем просто все заменить на нилы и поставить проверку нилов

плюсую.

Яваподходы.

просто тут руби еще( Вот в мире, где есть паттерн метчинг там еще красивее всё, т.к. можно матчится на этот NullObject…а в мире, где есть свёртки, можно `flatMap`’ом выкосить все NullObject’ы

Ну получит там пустую строку (например) вместо NoMethodError. Это если некритично. Если критично, то это другое дело, мб эксепшен, мб ещё что-то.

Яваподходы.

зря ты так, в Джавы много хороших архитектурных решений

ruby way - переопределить method missing )

вместо тысячи if\else\switch

зря ты так, в Джавы много хороших архитектурных решений

в джавы много решений которые хорошы только для джавы.

зря ты так, в Джавы много хороших архитектурных решений

просто там без этой архитектуры писать невозможно

ruby way - переопределить method missing )

он вроде дорогой, не?

дорогой, и кривой достаточно )

он вроде дорогой, не?

руби сам дорогой))

и вообще я бы это антипатеррном назвал )

зря ты так, в Джавы много хороших архитектурных решений

+1

но руби вэй

просто тут руби еще( Вот в мире, где есть паттерн метчинг там еще красивее всё, т.к. можно матчится на этот NullObject…а в мире, где есть свёртки, можно `flatMap`’ом выкосить все NullObject’ы

И в итоге всё равно в коде бесконечные if current_user ? и тп проверки.

И в итоге всё равно в коде бесконечные if current_user ? и тп проверки.

а это плохо?

ruby way - переопределить method missing )

В Confident Ruby и это описано :D для NullObject, но там свои проблемы, я бы такое не использовала.

а это плохо?

да, ветвящийся код всегда сложнее линейного

да, ветвящийся код всегда сложнее линейного

nullObject еще сложнее.

Я проверяю залогинен ли юзер, а он всегда залогинен

nullObject еще сложнее.

держать всю бизнеслогику в одной моделе user еще проще

держать всю бизнеслогику в одной моделе user еще проще

неа, как раз сложнее

ERROR: S client not available

я ж не говорю что гоу везде пихать их) где-то удобно, т.к. под задачу ложится…в руби есть nullObject = nil

У тебя должно быть прописано, что GuestUser не залогинен.

и чем дальше тем сложнее.

чего люди не придумывают, лишь бы констрейнты в базе не делать =)

чего люди не придумывают, лишь бы констрейнты в базе не делать =)

за констрейтами следить сложно

а в чём сложность? Эйрбрейк тебе напомнит если ты упустил что-то

У тебя должно быть прописано, что GuestUser не залогинен.

кстати да, вот GuestUser - NullObject очень красивый

вообще, единственный юзкейс для "nullobject" который мне нравится - это вот всякие анонимные юзеры и прочая лабуда

У тебя должно быть прописано, что GuestUser не залогинен.

ну у меня просто стоит before_action callback который проверяет наличие пользователя и обычным return unless кидает ошибки

нафига мне городить null object для этого?

ну у меня просто стоит before_action callback который проверяет наличие пользователя и обычным return unless кидает ошибки

вот мне это кажется гораздо более разумным

ну у меня просто стоит before_action callback который проверяет наличие пользователя и обычным return unless кидает ошибки

ой все

но наверное если интерфейс сильно похожий для анонимуса и нет, то будет хитрее

блин, как вы с колбэками живете то?

а если нужно в интерфейсе вывести типа “Гость”, показать “0” как колво сообщений и еще какие-то спец. выводы?

в 2k17 году

блин, как вы с колбэками живете то?

+++

больно

нафига мне городить null object для этого?

Тут скорее о других ситуациях. Например, надо написать "привет, юзернейм" vs "привет, гость".

блин, как вы с колбэками живете то?

коллбэк на authenticated? норм.

Тут скорее о других ситуациях. Например, надо написать "привет, юзернейм" vs "привет, гость".

если еще проще, null object это больше про отображение данных, чем про логику какую-то

Да, логики в самом nullobject немного.

собственно она “стабовая” = хардкод

Да, логики в самом nullobject немного.

не совсем

собственно она “стабовая” = хардкод

Ага.

вот есть у тебя null user который возвращает на name слово гость

а что он делает, когда на его мыло надо почту отправить?

когда надо ему в личку сообщение написать

все равно это все будет затыкаться ифами

просто в другом месте

а еще ему надо локаль проверять, что вернуть "гость" в правильной локали

В некоторых случаях возвращать nil, например )