Haciendo esfuerzos

Bien, ya encapsulamos todo y hemos hecho que nuestro código ahora luzca como una verdadera matrioshka... ¿Qué es lo que sigue? Ahora nos tocará ayudar a nosotros y los programadores del futuro.


¿Qué pasará cuando nos toque hacer mantenimiento y queramos añadir otra nueva característica? ¿Qué pasará cuando venga otro programador a actualizar nuestro código? Sinceramente esperamos que no suceda una catástrofe. Sinceramente creo que esto funcionará como un recordatorio para mi en el futuro también: un esfuerzo ahora nos ahorrará muchos problemas en el futuro.

Cuando diseñamos una aplicación a todos nos llega un momento de iluminación en el que conocemos absolutamente de nuestro código, sabemos qué hace esta parte, con qué otras partes se comunica y si quisiéramos modificar algo lo haremos en menos de 5 minutos, tanta es nuestra confianza que mientras revisamos cierta parte vemos otra oportunidad de encapsular más nuestro código sin embargo, no lo hacemos porque en ese momento somos los mejores programadores del mundo pero... ¿Qué pasa si nos llaman 6 meses después de terminar la aplicación para añadir una nueva característica? Quizá ya no estemos tan iluminados como antes y se nos haga un poco, en realidad muchísimo, más difícil agregar nuevas características porque no aprovechamos la oportunidad que tuvimos en el pasado.

Vamos delegando

puzzle

¿Qué es delegar? Este concepto es nuevo para mí y quizá para tí también pero no es difícil de comprender y hasta quizá ya lo hayas usado sin darte cuenta. Nosotros delegamos cuando hacemos que cierta tarea se hace en otro objeto en vez de hacerlo en el que estamos modificando directamente, algunas veces no se tiene que hacer toda la tarea en el otro objeto sino únicamente cierta parte de ella. ¿Recuerdas el método equals de Object en Java? Bueno, eso es precisamente es delegar: darle la responsabilidad de hacer cierta tarea a otra parte de nuestro código.

¿Por qué esto es bueno? Bueno, si delegamos dejamos que el otro objeto se preocupe de ejecutar la tarea que deseamos, esto hará que nuestro código pierda acoplamiento lo que es sumamente bueno: si no hay acoplamiento nuestros objetos podrán ser fácilmente reusados más adelante por otras partes de la aplicación. Cuando se pierde el acoplamiento todos los objetos en nuestra aplicación todos nuestros objetos tienen que hacer un trabajo en específico y hacen únicamente ese trabajo. De este modo la funcionalidad de nuestra aplicación estará bien definida para cada objeto y aunque hagan únicamente una tarea, la harán sumamente bien.

Todos contentos




Ya somos toda una máquina de solucionar problemas. Tano los clientes como los consumidores están contentos... ¿Qué sigue? Conquistar el mundo, claramente.

Recuerda que siempre puedes visitar la página de O'REILLY y comprar el libro del cual estos post están basados.

Comentarios

Entradas populares de este blog

Hagamos un breve repaso

El QQQ que no es malo

Casos de la vida real (en el diseño orientado a objetos)