Blog de Francisco Cifuentes

A continuación algunos de los tips de diseño software que me han servido para dejar mis diseños extensibles y elegantes. Utilizaré un diagrama de classes de ejemplo de un sistema de gestión de eventos para mostrar de mejor forma lo que cuento en cada punto.

• Programación por interfaces

Si tus classes tienen dependencias con otras, es mucho mejor depender de una interface (Classe Abstract o Interface), así pues puedes extender la funcionalidad agregando classes concretas que implementen la interface y por lo tanto nuevos comportamientos sin modificar otras clases (Una forma del principio open/close) 

En el diagrama de classes de ejemplo se ve en Role.

• Objetos como parámetros

No se porqué todos cuando salimos de la universidad tendemos a pensar en parámetros como variables nativas y no como objetos. La cosas es que si vas a pasar parámetros pasa objetos, por que de esa forma se cumple de mejor forma el principio de ocultamiento de la información, no nos engañamos diseñando con ropaje de objetos algo estructurado y lo que es mejor y más importante: Si necesitas más información para hacer algo en una operación que no te falten datos, es poco desafiante refactorizar por que hay un nuevo atributo.

Hay un excepción clara: Cuando traes desde la persistencia un objeto debes pasar el id (  event = eventDao.find(1); )

En el diagrama de classes de ejemplo se ve en EventManager.delete(Event event).

• Patrón de diseño estado (The state pattern)

Básico es que la oo se enfoca en el comportamiento, este patrón de diseño sirve para mandar a realizar operaciones que dependen del estado (si aplica por supuesto). En el caso del ejemplo el método remind envia mensajes a los participantes y como hay dos estados en el EventToBeDone si se envían y en el EventDone pues simplemente no se hace nada.

Lo espectacular de este patrón de diseño es que puedes agregar más estados sin problema (Pues depende de una abstracción) y que se evita implementar los comportamientos con if - switch y una casuística clásica estructurada.

Para quienes han mapeado classes desde la persistencia Hibernate implementa Discriminator Value para instanciar los objetos polimórficos e incuso Doctrine para php también con subClasses.

En el diagrama de classes de ejemplo se ve en EventState - la classe Event delega remind() en su estado.

• Estereotipo de clases de control o Managers

Para manejar objetos o una colleción de ellos existen los managers, y me ha resultado muy Útil que las operaciones de gestión sean su responsabilidad - en especial por que a través de estos mánagers puedes acceder a la persistencia (Utilizando clases DAO inyectadas por ejemplo). El beneficio más claro es que tienes una mejor separación en capas y en escencia unas responsabilidades mejor definidas.

En el diagrama de classes de ejemplo se ve en EventManager.

• Adios a los return

Es una de las herencias más dificiles de erradicar del pensamiento estructurado, tendemos a pensar en términos de llamada/respuesta, pero el envío de mensajes en la oo no funciona así es literalmente ""The process by which an object sends data to another object or asks the other object to invoke a method. (N.del T: El proceso en el cual un objeto envía datos a otro objeto o le solicita al otro objeto invocar un método)î.

No se quien le agregó a esto ... y esperar el return para hacer un if y avisar .....

Esto de los return usado sin ningun cuidad  tiene dos consecuencias: Acoplamiento y llenarse de if y switch.

Si una operación no se ejecuta o falla que no devuelva return - lanza una excepción que se despache a una vista de error!. El software debe ser diseñado como una mafia - nadie sabe quien hace las cosas, pero se hacen.

Claro que hay excepciones y son las que tienen que ver con traer objetos desde la persistencia. (dao.find(id), dao.findAll() )

Los indicados son los tips principales que puedo dar, conforme aprenda más y adquiera feedback y más experiencia creo podré aportar otros. ¿Qué les parece?. Si tienes un tip ponlo en los comentarios.

Saludos!