John recordó una historia de su experiencia pasada trabajando en un banco donde desarrollaron una aplicación del lado del cliente para ayudar a los agentes de ventas a calcular pagos de hipotecas y mostrar gráficos a los clientes. La aplicación fue exitosa, pero más adelante, los agentes solicitaron una versión web móvil que pudieran utilizar en sus teléfonos. La idea inicial fue conectarla al backend principal, pero debido a la falta de desarrolladores de mainframe, decidieron envolver los objetos de cálculo de hipotecas en un servicio web en su lugar. El servicio web se probó y funcionó bien, pero a veces produjo resultados absurdos, que eran difíciles de reproducir y diagnosticar. El problema finalmente se encontró que fue causado por un objeto singleton que no estaba limitado a una sola solicitud, lo que permitía que las solicitudes simultáneas se interfirieran entre sí. El objeto singleton era un resto de la aplicación cliente original, donde no era necesario hacer cumplir la unicidad. El calculador mantenía estado y probablemente no debería haber sido un singleton desde un principio. La solución fue simple, que fue dejar de utilizar el patrón singleton y asegurarse de que cada solicitud obtuviera su propia instancia del calculador. Esta experiencia sirve como ejemplo de la mala aplicación de patrones, destacando la importancia de una consideración cuidadosa al aplicar patrones de diseño al desarrollo de software. La historia demuestra cómo un problema aparentemente simple puede tener una causa compleja, y cómo una revisión cuidadosa del código y el diseño puede llevar a una solución sencilla.