Laravel по-русски
Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Страницы 1
Здравствуйте!
Вопрос вот в чем, если в коде вызвать
$exp = new MyModel()->where(...)...то если is_null($exp) - запись не найдена.
А как быть, если надо узнать внутри модели - загружена ли она? Например, если модель создана при помощи
$exp = new MyModel();а затем был вызван метод, который не должен отрабатывать на не загруженной модели.
Пока реализовал вот так:
if(!empty($this->original))Но кажется мне, должна быть как-то по-другому эта проверка выполняться.
Честно - искал ответ, но не нашел 
Ткните носом 
Благодарю.
Изменено mavsan (22.11.2016 07:46:18)
Не в сети
Я правильно понимаю, что если условие не выполняется, то объект не создается?
Если да, то как может быть вызван метод для несуществующего объекта?
Изменено Androbim (22.11.2016 09:51:18)
Не в сети
Проверить объект на предмет наличия, и, если он есть, вызвать метод. А что не так?
Не в сети
Мастер
Писарь
Учитесь обрабатывать сначала ошибки, а потом работать.
Не путать с исключениями!
$obj = Object::doSomething();
if ( !empty( $obj ) )
{
// работать с объектом
}
else
{
// делать что-то другое, попытаться другими способами получить объект
}
// и если совсем всё плохо и объект таки не получен - возвращать false из метода
// который так же можно обработатьНе в сети
Это будет небольшая специфичная библиотека. Я не знаю, как и что будет делать человек, который будет пользоваться ею, как он будет выполнять инициализацию конкретной модели (ни кто не мешает сделать new модель и попытаться вызвать метод, который предоставит доступ к скрытой информации). Поэтому хотел исключить потенциально опасную ситуацию. Но спасибо за ответы.
Не в сети
МастерПисарь
удивил. а меня редко в этой жизни можно удивить, - типа не впечатлительный.
разработчик в первую очередь обязан понимать для чего и зачем он творит свой код!
иначе будет кодинг ради кодинга. машинный труд робота-обезьяны.
в этом случае тебе надо сменить фреймворк на yii.
Не в сети
Если библиотекой будет пользоваться сторонний разработчик, пусть он и думает о том, что делать, если, к примеру, объект не был создан. В контексте вопроса, это забота клиентского кода.
Не в сети
Мастер 
Эм, речь идёт о $this->exists ? (если модель загружена из бд или была сохранена ->save то exists примет значение true).
class Post extends Model
{
public function notificateUsers()
{
if (! $this->exists) {
throw new \Exception('wtf?');
}
// ...some code...
}
}Изменено covobo (29.11.2016 21:29:01)
Не в сети
Спасибо тебе, Человечище!!!
Не в сети
С другой стороны - это exists - публичное, т.е. ни что не мешает кому-то сделать new Модель(), затем присвоить этой exists - true, блин дырища-то какая!
Не в сети
МастерПисарь
С другой стороны - это exists - публичное, т.е. ни что не мешает кому-то сделать new Модель(), затем присвоить этой exists - true, блин дырища-то какая!
ну попробуй потом расскажи.
Не в сети
Мастер С другой стороны - это exists - публичное, т.е. ни что не мешает кому-то сделать new Модель(), затем присвоить этой exists - true, блин дырища-то какая!
Ну, было бы это поле приватным - был бы ужас.
А protected/public - уже нет разницы, всегда можно написать метод setExists(bool $value) { $this->exists = $value }
Не в сети
Если следовать принципам (я думаю - их не зря не глупые люди придумывали) ООП, инкапсуляции в частности, это не правильно. ВСЕ свойства должны быть private/protected, а доступ к ним средствами методов. Конкретно свойство, которое сообщает внешнему миру о внутреннем состоянии модели - однозначно не должно быть публичным, а приватным (даже не защищенным, чтобы наследники не могли менять).
Изменено mavsan (01.12.2016 03:33:34)
Не в сети
Если следовать принципам (я думаю - их не зря не глупые люди придумывали) ООП, инкапсуляции в частности, это не правильно. ВСЕ свойства должны быть private/protected, а доступ к ним средствами методов. Конкретно свойство, которое сообщает внешнему миру о внутреннем состоянии модели - однозначно не должно быть публичным, а приватным (даже не защищенным, чтобы наследники не могли менять).
Вы джавишник что ли?)
10 свойств = 10 геттеров/сеттеров чето слишком много
Не в сети
Мастер а приватным (даже не защищенным, чтобы наследники не могли менять).
Ну, предлагаю попробовать теперь переписать всё так, чтобы exists мог быть приватным.
Удивишься.
Например - трейт SoftDelete - он работает с свойством exists, че делать теперь?
Или Illuminate\Database\Eloquent\Relations\Pivot
Или теперь весь код дерьмо?
Изменено covobo (01.12.2016 10:43:33)
Не в сети
Мастер Понять твоё негодование можно, но, конкретный кейс - это всё таки не класс операционной системы от которого зависит стабильность системы в целом.
Не в сети
Если следовать принципам (я думаю - их не зря не глупые люди придумывали) ООП, инкапсуляции в частности, это не правильно. ВСЕ свойства должны быть private/protected, а доступ к ним средствами методов
Процедурный подход тоже не идиоты придумали, как и Laravel. Для меня главная прелесть Laravel как раз в том, что он не старается слепо следовать моде, коей сейчас является подход, описанный выше.
Изменено AlexeyMezenin (01.12.2016 12:12:29)
Не в сети
Мастер 
Давать доступ к полям через accessors это правильно хотя бы потому, что в будущем возможно изменение логики. Если кажется, что поле не затрагивает другие поля (состояние) и его можно свободно читать/писать, то потом это часто меняется, а так как синтаксис вызова метода и чтения/записи поля разный (в отличии от JS), то приходится менять код за пределами класса. И единообразия нет — надо помнить, когда это поле, когда это метод, даже если за методом простое скалярное значение. Лучше уж всегда делать метод и не задумываться.
Это порождает 100500 методов, что не красиво, но в PHP вариантов нет (не как в Ruby, где accessor’ы создаются одной строкой, что очень удобно).
- Конкретно свойство, которое сообщает внешнему миру о внутреннем состоянии модели — однозначно не должно быть публичным, а приватным (даже не защищенным, чтобы наследники не могли менять).
Наследование для того и придумано, чтобы потомки могли частично использовать состояние. Я лично всегда использую только protected, так как чтобы наследовать класс надо по определению знать его внутреннюю работу, и private только раздражает, когда тебе надо изменить одну-единственную строку, но вместо этого приходится копировать половину кода базового класса или придумывать другие велосипеды, чтобы обойти чрезмерно заботливого автора.
- Например — трейт SoftDelete — он работает с свойством exists, че делать теперь?
Типажи это отдельная проблема и с ними легко наломать дров, в том числе из-за коллизий имён. exists — не самое редкое слово в обиходе программиста.
Не в сети
Мастер и private только раздражает, когда тебе надо изменить одну-единственную строку.
Особенно если это сторонний пакет, судя по вашим словам, вы о нём и говорили.
Дополню ещё по поводу private.
Все мы любим SOLID, один из принципов:
Принцип открытости/закрытости (The Open Closed Principle)
«программные сущности … должны быть открыты для расширения, но закрыты для модификации.»
Рассмотрим две истории:
1) Программист скачал скомпилированную библиотеку на Java, понял, что он не может расширить класс из-за, допустим, private методов и проклял автора, т.к. автор оставил свой класс закрытым для расширения, от библиотеки пришлось отказаться.
2) PHP программист поставил пакет через composer, понял, что private ему не подходит, перенёс нужный файл пакета себе в проект, изменил private на protected (модифицировал исходный класс), composer dumpautoload собрал ему всё как надо - не задумываясь пошел работать дальше.
Вывод - Java не очень.
Шутка.
Рассматривайте свой код так, будто его никто не сможет потом модифицировать - сразу появится отвращение к private и многострочным методам.
Изменено covobo (03.12.2016 23:13:25)
Не в сети
Страницы 1
Универсальная вики-разметка
Работает на FluxBB (перевод Laravel.ru)