Por lo tanto, tengo un servicio web que tiene algo así como un getAccountlugar en el que devolvería un identificador a la cuenta si lo tuviera, de lo contrario arrojaría una excepción. El cliente siempre querrá crear una cuenta si se produce una excepción con la misma información con la que se realiza la obtención.
Estoy creando una biblioteca de conveniencia para los clientes que manejará todas las llamadas de servicio web en el interior para que no necesiten saber cómo hacer las llamadas ellos mismos.
Lo que me pregunto es en esta biblioteca si tuviera que crear una getAccount(accountName)que obtenga la cuenta si existe, y si no la crea y devuelva la información, ¿es algo malo? ¿Debo dejar que el cliente maneje las excepciones o simplemente nombrarlo como getOrCreateAccount? ¿Importa?
¿Es una mala práctica crear algo en una operación get?
fuente
getOrCreateAccounto similar.acquirelikeacquireAccount. No tiene un significado existente en ninguno de los protocolos principales que he encontrado, y tiene un tono imperativo que le queda bien. "Haz lo que tengas que hacer para adquirir uno de estos para mí. Solicítalo, construyelo, fingelo, robo, no me importa, solo consígueme uno o muere en el intento".getSomething()es para getters ysetSomething()para setters. Imo cualquier cosa que hace algo más intelectual debe ser llamado otra cosa, es decirfetchSomething,obtainSomething,computeSomething, odoSomethingElseetcRespuestas:
Si importa. En mi opinión, generalmente es una mala práctica crear algo en un procedimiento que no está documentado como que tiene los poderes de la creación. Ya sea nombrar el procedimiento
getOrCreate...o tener uncreate...procedimiento separado y luego, si realmente lo desea, tener ungetOrCreate...primer intentoget..., y si eso falla, llamacreate...y luego llamaget....El usuario de la biblioteca probablemente no esperará
get...que se cree el procedimiento si falla la operación de obtención. Si de repente descubren que sus llamadas de pruebaget...crearon una tonelada completa de datos, probablemente se sorprenderán bastante. ¿Y cómo lo limpian? ¿Qué pasa si escriben código pensando que obtendrán un error siget...falla y quieren manejarlo a su manera?fuente
get...create...get...solo los dos primeros. Hablaré con el cliente sobre si alguna vez requerirán la capacidad de simplemente llamar a ungetsin querer crearcreateen el nombre, solo para ser 100% claro sobre lo que está sucediendo.getOrCreatetiene prioridad en un marco web popular: docs.djangoproject.com/en/1.10/ref/models/querysets/…No, no es 'mala práctica'. Mientras usted y los otros desarrolladores estén de acuerdo en que así quiere que funcione, está bien. Después de todo, sería devolver una cuenta, que es lo que quieres. Que la cuenta se cree 'bajo el capó' es irrelevante para la persona que llama.
fuente
Si
getAccount()siempre puede devolver una cuenta, desde el punto de vista de la persona que llama, la cuenta existe, y siempre ha existido. No hay necesidad degetAccount()'crear' nada. La cuenta no tiene que almacenarse en ningún lugar hasta que sea diferente de la cuenta predeterminada.fuente
GetOrCreatees la semántica incorrecta, pero obtener un objeto que pueda existir "lógicamente", ya sea que exista o no físicamente, está bien. Como ejemplo, una matriz dispersa de elementos mutables puede no tener ningún almacenamiento asignado para el elemento 1,841,533, pero aún así permite que ese elemento sea "recuperado" creando un nuevo objeto, almacenándolo y devolviendo una referencia.Tiene más sentido crear 3 métodos:
getAccount -> Que solo obtiene la cuenta.
createAccount -> Crea una cuenta.
getAccountAndCreateIfNeeded -> Elija su propio nombre;)
Por qué separación: tiene un método simple para obtener y crear. Ese es un método claro y comprobable para ambos. Para getAccount no es una excepción no encontrar la cuenta. Así que solo devuelve falso o algo así, se espera.
Luego puede usar ese valor de retorno en su función agrupada: getAccountAndCreateIfNeeded que ahora también es comprobable, debería devolver una cuenta siempre. Lo que sea que pidas.
Todos estos 3 métodos son claros, es exactamente claro lo que hacen y lo que devuelven. Puede llegar a acuerdos ahora con su equipo, pero este tipo de excepciones son terribles a largo plazo. Simplemente déjelos muy claros y no tendrá problemas.
fuente
getAccountIfExistsque obtendría una cuenta o indicaría que no existe sin crear una nueva. ElgetAccountmétodo en sí mismo debe presuponer que la cuenta existe, y lanzar una excepción si no.Depende de las circunstancias.
Por ejemplo, puede usarlo para cargar / crear instancias diferidas, aplazando la carga de datos o la creación de una instancia hasta que sea realmente necesaria. Esto normalmente es sensato ya que ahorra recursos que quizás no necesite (si la clase / datos nunca se necesitan, nunca se cargan).
Sin embargo, en este caso particular, diría que tener un método llamado getAccount que crearía una nueva cuenta si no existiera no sería una buena práctica. Si el usuario ha dado algunas credenciales para identificar una cuenta en particular y esa cuenta no se pudo encontrar, ¿eso significa que el usuario aún no es un cliente y debe tener una cuenta creada para ellos, o significa que las credenciales se escribieron incorrectamente? ¿y se le debe pedir al usuario que verifique que ha ingresado lo que quería ingresar?
Si tiene un método getAccount que crea una nueva cuenta si no puede identificar una, entonces no tiene otra opción. Si divide la creación de la cuenta y la salida de la cuenta en métodos separados, entonces tiene mucha más flexibilidad para decidir qué hacer si falla un intento de obtener una cuenta.
fuente