¿Es buena/práctica de programación de sentido común hacer que todos los métodos devuelvan un objeto MyResult en PHP?

Question

Trabajando a través de varias capas de un programa diseñado de arquitectura MVC, me parece que me gustaría obtener más información sobre el resultado del retorno de método de una capa más profunda, y que no siempre puedo prever cuándo necesitaré esta información. Y, en aras de la abstracción, es posible que no desee que ese método genere material para el registro específico de la aplicación (ese método podría usarse en un programa diferente) o que tenga un comportamiento específico dependiente de la aplicación como otras capas anteriores.

Por ejemplo, en una función de utilidad dada puedo tener varias verificaciones de requisitos previos antes de ejecutar una acción, que fallan. Si devuelvo falso en alguno de ellos, la persona que llama no sabe lo que sucedió. Si devuelvo falso y registro en el registro de la aplicación lo que sucedió, estoy limitando esa función al comportamiento específico de la aplicación.

La pregunta es: ¿es buena/común aplicar una pequeña clase llamada MyResult y hacer que devuelva el estado de respuesta (correcto/falso), un mensaje, un código entero eventual y un marcador de posición de objeto (matriz u objeto) donde la persona que llama podría acceder al objeto devuelto? Esta clase MyResult se usaría en todo el sistema y sería un "dialecto" común entre todos los métodos y sus interlocutores. Todos los métodos devolverían una instancia de MyResult, todas las veces.

Answer 1

¿Podría dar un ejemplo? Parece un poco, pero puedo estar equivocado, que tienes métodos que estás usando estáticamente (incluso si no están implementados/llamados así podrían haber sido). El ejemplo básico del objeto de tabla que se puede pintar se llama así: $myTable->paint();. Puede devolver una variable si funcionó o no (verdadero/falso) pero cualquier otra cosa (como el registro) es una función de table() y ni su método de llamada, ni el valor de retorno deberían tener nada que ver con eso en cuanto a I ' m preocupado

Tal vez me está costando entender por qué situación va a usar esto, pero si quiere enviar mensajes para algún propósito que requiera mensajes (o eventos, etc.) debe definirlos, pero yo no No veo ningún mérito en la definición de un returnObject predeterminado para pasar los resultados de la llamada al método.

Para los errores tiene dos opciones: excepciones (es decir, cosas que realmente no espera que sucedan y deben detener la ejecución) y errores: comportamiento esperado pero no deseado. El primero debe ser dejado en paz, el segundo puede ser complicado, pero yo diría que el objeto en sí debe contener un estado que aclare lo que sucedió.

Answer 2

Si un marco no ofrece una función específica que necesita, no hay otra manera que usted mismo. Especialmente si necesita algo que atraviesa los objetivos del marco, nunca lo lograría.

Sin embargo, muchos marcos ofrecen lugares en los que puede ampliarlos. Algunos son más flexibles que otros. Entonces, si es posible, vería si todavía puede implementar su característica necesaria como un tipo de complemento, complemento o código auxiliar que pueda permanecer dentro del terreno del marco.

Si eso no es posible, yo diría que siempre es válido hacer lo que quiera hacer. Usa la parte del marco que es útil para ti.

Answer 3

Para eso están las excepciones. No tiene que sobrepasarlos como Java, pero existen porque los códigos de error son una mierda.