"La conveniencia no es una -ilidad"

Consejos de programación para #programadores.

-----------------------------------------------------------------------

LIBRO: 97 COSAS QUE TODO PROGRAMADOR NECESITA SABER.

POR: KEVLIN HENNEY.

-----------------------------------------------------------------------

18° "LA CONVENIENCIA NO ES UNA -ILIDAD":

Mucho se ha dicho sobre la importancia y los desafíos de diseñar buenas API. Es difícil acertar la primera vez y es aún más difícil cambiar más tarde, algo así como criar niños.

Los programadores más experimentados han aprendido que una buena API sigue un nivel consistente de abstracción, exhibe su consistencia y simetría, y forma el vocabulario para un expresivo lenguaje. Por desgracia, ser consciente de los principios rectores no significa automáticamente traducirse en un comportamiento adecuado. Comer dulces es malo para ti.

En lugar predicar desde lo alto, quiero elegir un diseño de API en particular “estrategia”, una que encuentro una y otra vez: el argumento de la conveniencia.

Por lo general, comienza con una de las siguientes "percepciones":

• No quiero que otras clases tengan que hacer dos llamadas separadas para hacer esto.

Una cosa.

• ¿Por qué debería hacer otro método si es casi igual a éste método?

Solo agregaré un interruptor simple.

• Mira, es muy fácil: si el segundo parámetro de cadena termina en “.txt”, el método asume automáticamente que el primer parámetro es un nombre de archivo, por lo que realmente no necesita dos métodos.

Aunque bien intencionados, tales argumentos son propensos a disminuir la legibilidad de código usando la API. Una invocación de método como:

analizador.processNodes(text, false);

no tiene prácticamente sentido sin conocer la implementación o al menos consultar la documentación. Éste método probablemente fue diseñado para la conveniencia del implementador en oposición a la conveniencia de la persona que llama: "No quiero que la persona que llama tenga que hacer dos llamadas separadas" traducido a "No quería codificar dos métodos separados”. No hay nada fundamentalmente malo con conveniencia si está destinado a ser el antídoto contra el tedio o torpeza. Sin embargo, si lo pensamos un poco más detenidamente, el antídoto a esos síntomas es eficiencia, consistencia y elegancia, no necesariamente conveniencia.

Se supone que las API ocultan la complejidad subyacente, por lo que, de manera realista, podemos esperar que un buen diseño de API requiera algo de esfuerzo. Un único gran método ciertamente podría ser más conveniente para escribir que un conjunto bien pensado de operaciones, pero ¿sería más fácil de usar?.

La metáfora de la API como lenguaje, puede guiarnos hacia mejores decisiones de diseño en éstas situaciones. Una API debe proporcionar un lenguaje expresivo, lo que da la siguiente capa por encima de suficiente vocabulario para hacer y responder preguntas útiles.

Ésto no implica que deba proporcionar exactamente un método, o verbo, para cada pregunta que puede valer la pena hacer. Un vocabulario diverso nos permite expresar sutilezas en el significado. Por ejemplo, preferimos decir correr en lugar de caminar (verdadero), aunque podría verse como esencialmente la misma operación, simplemente ejecutada a diferentes velocidades.

Un vocabulario API consistente y bien pensado hace para un código expresivo y fácil de entender en la siguiente capa. Más importante aún, un vocabulario componible permite que otros programadores usen la API en formas que quizás no haya previsto: una gran comodidad para los usuarios de la API. La próxima vez que tenga la tentación de agrupar algunas cosas en un método API, recuerda que el idioma inglés no tiene una sola palabra para MakeUpYourRoomBeQuietAndDoYourHomeWork, aunque sería realmente conveniente para una operación solicitada con tanta frecuencia.

-Gregor Hohpe-