Это хорошая практика программирования здравого смысла, чтобы все методы возвращали объект MyResult в PHP?

Question

Прорабатывая несколько уровней программы, разработанной для архитектуры MVC, я обнаружил, что хотел бы получить больше информации о возвращаемом методе более глубокого уровня результате, и что не всегда я могу предвидеть, когда мне понадобится эта информация.И - ради абстракции - я мог бы не захотеть, чтобы этот метод выводил данные в журнал приложения (этот метод мог использоваться в другой программе), или имел бы специфическое поведение, зависящее от приложения, как и другие уровни выше.

Например, в данной служебной функции у меня может быть несколько предварительных проверок перед выполнением действия, которое завершается неудачей.Если я верну false на любом из них, звонящий не будет знать, что произошло.Если я возвращаю false и записываю в журнал приложений то, что произошло, я ограничиваю эту функцию специфическим поведением приложения.

Вопрос в том, является ли это хорошей / обычной практикой для реализации небольшого класса с именем MyResult и возвратастатус ответа (ok / false), сообщение, возможный целочисленный код и заполнитель объекта (массив или объект), где вызывающий может получить доступ к возвращенному объекту?Этот класс MyResult будет использоваться во всей системе и будет общим «диалектом» между всеми методами и их вызывающими.Тогда все методы будут всегда возвращать экземпляр MyResult.

Answer 1

Вот для чего и исключения. Вам не нужно переусердствовать с ними, как с Java, но они существуют, потому что коды ошибок отстой.

Answer 2

Не могли бы вы привести пример? Кажется немного, но я могу ошибаться, что у вас есть методы, которые вы используете статически (даже если они не реализованы / не вызваны так, как могли бы). Основной пример табличного объекта, который может рисовать сам, называется так: $myTable->paint();. Он может возвращать переменную, если она работает или нет (true / false), но любая другая вещь (например, ведение журнала) является функцией table(), и ни ваш вызывающий метод, ни возвращаемое значение не должны иметь ничего общего с этим, если Я обеспокоен.

Может быть, мне трудно понять, для какой ситуации вы собираетесь использовать это, но если вы хотите отправлять сообщения для какой-то цели, которая требует сообщений (или событий и т. Д.), Вы должны определить их, но я не Не вижу смысла в определении возвращаемого объекта по умолчанию для передачи результатов вызова метода.

Для ошибок у вас есть два варианта: исключения (то есть: вещи, которые вы действительно не ожидаете и должны остановить выполнение) и ошибки: ожидаемое, но нежелательное поведение. Первое должно быть оставлено в покое, второе может быть сложным, но я бы сказал, что сам объект должен содержать состояние, которое проясняет, что произошло.

Answer 3

Если инфраструктура не предлагает нужную вам особенность, другого способа, чем вы, позаботитесь самостоятельно.Особенно, если вам нужно что-то, что идет вразрез с целями фреймворка, поэтому никогда не сделаете это.

Однако многие фреймворки предлагают места, в которых вы можете их расширить.Некоторые из них более гибкие, чем другие.Поэтому, если возможно, я бы посмотрел, можете ли вы реализовать нужную вам функцию в виде типа надстройки, плагина или вспомогательного кода, который может оставаться в пределах фреймворка.

Если это невозможно, я бы сказалвсегда в силе делать то, что вы хотите сделать.Используйте ту часть фреймворка, которая вам пригодится.