Sé que es costoso pero (OMI) creo que es una muy buena práctica. Estoy hablando de reglas como, por ejemplo, no puede guardar una factura si no es un vendedor ... así que, en ese caso, lanzar una excepción que diga 'no está autorizado' o tal ...
Otro enfoque sería tener objetos con un estado o algo así
¿Hay algún otro enfoque? ¿Cómo te sientes al respecto?
Respuestas:
Si te refieres a representar verificaciones de reglas de negocios individuales con excepciones, entonces no creo que sea una muy buena idea. Muchas veces tiene que informar más de una condición fallida y no detenerse en la primera.
Por otro lado, creo que verificar todas las reglas y luego lanzar una excepción con el resumen es una buena práctica.
JamesPoulsonExceptioncomo una subclase de RuntimeExceptiony luego proporcionar la excepción original como cause. Entonces puedes simplemente decir if (exception instanceof JamesPoulsonException)... para diferenciar. Use el getCause()método para alcanzar la excepción original.
En el ejemplo que nos ha dado, creo que plantear una excepción es una mala idea. Si sabe que el usuario no está autorizado antes de que comience a trabajar y aún así le permite realizar alguna función y luego lo golpea con un mensaje DESPUÉS de que ya ha completado la tarea, es un mal diseño.
Usar excepciones para hacer cumplir las reglas comerciales no es un buen diseño.
No veo qué valor tiene arrojar una excepción al crear una buena lógica de negocios. Hay docenas de enfoques para manejar la lógica empresarial que no implican el uso de un sistema destinado a abordar condiciones inesperadas en la operación de un sistema.
Se espera que, en la lógica empresarial, no se cumplan las condiciones; esa es la razón para tenerlo en primer lugar, y no desea aprovechar el mismo mecanismo que maneja fallas de E / S inesperadas, errores de falta de memoria y referencias nulas. Esas son fallas del sistema, pero detectar condiciones comerciales no satisfechas es la operación exitosa del sistema.
Además, es un sistema que está listo para consecuencias no deseadas. Debido a que se debe detectar una excepción en algún momento, corre el riesgo de que una nueva excepción de la regla de negocios se vea atrapada en algún lugar que no está destinada o puede tener el código que busca reglas de negocios que capturen excepciones que en realidad no están destinadas para ello. Sí, estas condiciones pueden explicarse con buenas prácticas de codificación, pero en cualquier sistema no trivial en el que trabaje más de un desarrollador, ocurrirán errores, y solo tiene que esperar que no sean errores costosos.
expresar reglas comerciales es una cosa, implementarlas es otra
pensar en la experiencia del usuario; si el usuario no es un vendedor, por eso les dará un botón que dice 'Crear factura' en absoluto ?
Eso depende completamente de lo que se esté haciendo.
Primero, ¿cuál es el comportamiento real que quieres? Si alguien está ingresando su propia información, entonces un rechazo y un cuadro de diálogo que dice, esencialmente, "No puedes hacer eso" probablemente sea correcto. Si se trata de una persona que ingresa datos, trabajando desde una pila de formularios, un cuadro de diálogo probablemente también sea bueno, y la persona que ingresa los datos puede colocar los formularios no válidos en una pila especial. Si está realizando un procesamiento por lotes, no desea detener las cosas, sino marcarlo y pasar al siguiente.
Una vez que tenga el comportamiento, debe decidir cómo lo va a implementar. Probablemente sea una buena idea tener un verificador de reglas de negocio que arroje una excepción. Devolver un código de retorno y hacerlo pasar es otra cosa que puede salir mal, y ciertamente no desea que las entradas erróneas vayan más allá.
No se preocupe por los gastos de rendimiento. En el caso de que una persona ingrese datos, es trivial en comparación con las otras veces involucradas. Típicamente, el humano tomará más tiempo en ese sistema. En el caso de un trabajo por lotes, si las excepciones son un problema de rendimiento, está ingresando demasiados registros incorrectos y, en realidad, manejar y volver a ingresar todos esos será un problema mayor que las excepciones.
Tener una API de excepción robusta y bien diseñada que sea consistente es muy apropiado. Usar esto para hacer cumplir las reglas comerciales también puede ser apropiado. De hecho, en mi experiencia, cuanto más complicada es la regla de negocios, más probable es que termine siendo manejada de esta manera. A menudo es tan fácil, si no más fácil, escribir un sistema donde se esperan excepciones que escribir una lógica de ramificación autorizada.
Esto quiere decir que las reglas simples que se pueden describir en una sola oración generalmente deben implementarse de manera preventiva o autorizada, según cuál sea. Sin embargo, si tiene una regla que es multidimensional y requiere más de tres o cuatro factores (especialmente si la selección de estos factores se basa en uno o más de los otros factores), entonces la codificación de excepción puede ser más fácil de mantener. A menudo, en estos casos, la ruta lógica tendrá muchas excepciones precursoras que deben lanzarse (verifica por qué no se puede realizar la acción) y luego (o viceversa) hay una caída en la seguridad (para verificar que la acción esté autorizada ), a veces habrá alguna lógica de acumulación autorizada que debe verificarse (disponibilidad descendiente / ancestro, estados precursores en los que se deben colocar los objetos, etc.
Un beneficio que se deriva de este tipo de lanzamiento de excepciones es que le permite separar y reutilizar las excepciones precursoras en múltiples áreas de su proyecto. (Esta es la esencia de la Programación Orientada a Aspectos). Al hacer esto, está encapsulando un aspecto particular de sus reglas comerciales generales en un componente autónomo y mantenible. En general, estos componentes corresponderán 1-1 con los mensajes de error lanzados. (Aunque a veces tendrá un componente que arroja varias excepciones diferentes, casi nunca debería tener la misma excepción lanzada desde múltiples componentes).
En mi opinión, es más difícil diseñar sistemas que se basen en excepciones y el tiempo de desarrollo inicial es más largo ya que tiene que construir el proceso de excepción en todos los N niveles. Sin embargo, estos sistemas generalmente terminan siendo mucho más estables. Si bien nunca es posible diseñar un sistema que 'no fallará', el beneficio del diseño basado en excepciones es que siempre está anticipando la falla. Para la mayoría de las personas, el proceso puede ser contra intuitivo. Es como pedir indicaciones y que alguien te diga todas las calles que no debes encender.