La taza de café de la vergüenza

Así que estaba por Facebook cuando veo, por enésima vez, aparecer una taza de café con algo de código (C# seguramente) que trata de ser simpática. Además, termina el código con un comentario:

//I am a software developer

Y no puedo por menos que pensar que si has escrito un código así, y eres desarrollador, seguramente te parezcas mucho a este:

soy_programador

Veamos el código que hay en la taza:

La taza en concreto

La taza en concreto

El primer fallo es que si el café (que no la taza) está vacío, este se rellenará, pero no se beberá. Lo que necesita esta función no es un bloque if-else, es una guard clause que asegure que se cumple la precondición necesaria para el éxito (es decir, que se cumple que efectivamente haya café, para poder beberlo). Una mejor versión entonces sería la siguiente:

Sin embargo, sigue teniendo algo que me trae la cabeza loca. El café se está creando en la misma función. Una guard clause tendría sentido si lo recibiésemos como parámetro, ya que no podemos asegurar su estado. Pero si lo creamos una línea por encima, y su ámbito es local (por lo que no va a ser modificado en otra parte del mismo código), ¿no podemos asegurar que va a estar vacío o lleno de antemano? ¿El constructor es mágico? ¿No cumple ningún contrato? ¿Si el segundero del reloj marca un número primo y fuera hace sol, la taza estará llena, y en caso contrario estará vacía? Vale, supongamos que el café está vacío siempre para objetos recién instanciados.

Esto tiene un poco más de sentido. Pero poco. ¿Por qué es el propio café quien se bebe? ¿Qué clase de caníbal asignaría la responsabilidad de ser bebido al propio café? Lo lógico sería que el café implementase algún tipo de interfaz (por ejemplo, Drinkable), y que sea otro quien se beba al café. Por ejemplo:

En cualquier caso, estamos dando por sentado que el café va a estar vacío, y que hay un único tipo de café en el mundo. Lo cuál no es cierto (por mucho que me gustase que así fuese). Lo tenemos con leche, sin leche, con azúcar, con nuez moscada, con nata… Así que casi mejor hacemos el constructor de café como privado y permitimos únicamente obtener instancias de la clase mediante métodos estáticos (a no ser que nos queramos liar la manta a la cabeza metiendo una jerarquía de herencia, lo cuál terminaría siendo un caos debido a que un café con azúcar es distinto a uno con leche, pero podemos tener un café con leche y con azúcar).

Pero claro, como las combinaciones van a ser muchas, casi mejor utilizamos un patrón Builder. Además, como es café, en vez de utilizar la nomenclatura Builder, se presta mucho a utilizar Brewer (cafetera). Así que hagamos nuestra cafetera.

Esto ya es otra cosa.

3 comentarios en “La taza de café de la vergüenza

  1. Es una simple broma, vamos hombre que si fuera por buenas practicas hasta los condicionales le volaría con un funtor aplicativo, es mas hasta podrías ponerlo en un applier combinándolo con una monada maybe y ejecutar la función solamente si paso x cantidad de comprobaciones, pero me parece demasiado. No veo la necesidad de analizar y hacer un post sobre el estampado de una taza, me parece exagerado.

    • Todos y ninguno, Martin. Al fin y al cabo no he hecho más que suposiciones de cuál es el código que rodea a la pieza de la taza, y a cuál puede ser su utilidad. Si bien es cierto que cosas tales como implementar un patrón builder cuando puede que las opciones sean escasas (cafeinado o descafeinado simplemente) es seguro un over-kill (keep it simple, stupid!), otras como las guard clauses son (o al menos me lo parecen) una buena práctica en cualquier sitio.

      De todas formas no hay que tomárselo más en serio de lo que es, una taza humorística analizada en clave de humor igualmente.

Deja un comentario