En el próximo dojo de Huesca volveremos a intentar desarrollar APIs fluidas. Esta vez, a diferencia de Madrid, todos iremos a por la misma API para reducir complejidad y mal entendidos.
Qué es una API fluida? Básicamente una API que es más humana de leer. Podeis leer a Martin Fowler sobre ello aquí. Hay varias estrategias para desarrollar APIs fluidas. Nosotros utilizaremos métodos encadenados (method chaining).
Las APIs fluidas son muy cómodas de usar (véase la API de mockito para definir stubs o mocks). Sin embargo, su implementación no es trivial. De hecho, su código es complejo. Al fin y al cabo estamos creando casi un DSL y esto se acerca a la teoría de compiladores.La mejor manera de lidiar con problemas complejos es con código limpio, que exprese claramente su cometido.
Todavía no sé si es muy docente mezclar TDD con el diseño de APIs fluidas pero es una buena oportunidad para probarlo. Da mucho juego para usar dobles de prueba o no usarlos, o para escoger enfoque top-bottom o bottom-up. Despues de varios intentos podremos volver a probar retrospectiva.
En el dojo que hicimos en Autentia propuse 4 ejercicios diferentes. Podeis ver la implementación de Rafa de Castro aquí, de uno de ellos. En mi opinion muy buena aproximación.
Mi propuesta para este dojo de Huesca es implementar esta API:
- select(“name”).from(users)
- select(“name”).from(users).where(“age”).greater_than(18)
- select(“name”).from(users).where(“surname”).contains(“rodriguez”)
- select(“name”).from(users).where(“age”).greater_than(18).and(“location”).is(“san francisco”)
Como se ve, la complejidad va en aumento. La idea es que quien termine una, pueda saltar a la siguiente. No me importa qué representación tenga “users”, aunque para mi sería una lista de objetos User. Lo que estamos haciendo aqui es algo parecido a Linq de .Net. No me meto a difinir como sería el assert de la especificación, solo os propongo estas líneas como parte del acto (ACT), de la especificación, es decir, quiero tener esa API disponible en mi libreria para usarla cuando quiera filtrar información de objetos.
Si nunca has visto una API fluida te puede parecer imposible pero no lo es. La cuestion es que con los métodos encadenados, un método no tiene por que devolver un tipo primitivo sino que puede devolver otro objeto 😉
No hace falta saber TDD para venir, pero sí sera bueno conocer algun framework de testing unitario. JUnit si quereis usar Java. Yo haré la kata en Python. Si quereis usar Ruby o lo que sea, es OK 🙂
Nos vemos en Huesca 🙂