martes, 17 de marzo de 2015

Open Close Principle


Open Close Principle

Una de las características del desarrollo de software, es que el software debe de estar diseñado para cambiar, alguna vez leí que el software que no cambia tiende a morir, bajo esta idea, el software que se mantiene evolucionando, agregando nuevas funcionalidades, mejorando las que ya se tienen, innovando, ... es el software que sobrevive. Pero, para que un software sea mejorado y/o aumentado debe de contar con ciertos principios que permitan evitar que un pequeño cambio tenga efectos no deseados en otras secciones de código.

En este blog analizaremos el principio Open Close Principle, este principio establece que el diseño de software deberá ser hecho de una forma que las nuevas funcionalidad sean agregadas con mínimos cambios en el código existente. La idea es que al agregar nuevas funcionalidades se haga mediante nuevas clases, manteniendo lo mas posible sin cambios el código que ya existe.

Por lo anterior, la máxima del principio Open Close es: Open para extensión, Close para modificación.

Lo que quiere decir es que se debe de evitar modificar código ya creado, y tratar de hacer uso de técnicas de diseño orientado a objetos tales como interfaces y clases abstractas.



En el siguiente ejemplo se tiene una clase que envía 3 tipos diferentes de mensajes, las implementaciones para cada tipo de mensaje se encuentra en una clase concreta que implementa la interface Message. La clase MessageSender tiene un método llamado sendNotification que recibe un tipo de objeto Message, de manera que podemos tener muchas implementaciones y esta clase no se ve afectada de ninguna manera.




En el diagrama podemos observar que si se desea agregar un nuevo tipo de mensaje no es necesario modificar nada de las clases ya existentes (Close para modificaciones), por otro lado, solo se requiere crear la nueva implementación del tipo de mensaje que se desee extendiendo de la clase abstracta o interface Message (Open para extensión).

En caso de que las implementaciones se encontraran en una sola clase(rompiendo el principio Open Close), cuando se desea agregar un nuevo tipo de mensaje es necesario modificar esa clase y posiblemente realizar cambios al código ya existen, con lo cual se viola el principio de Open Close.


Código:
public class SenderNotification {
public Boolean sendNotification(final Message message) {
return message.sendMessage();
}
}


public interface Message {

Boolean sendMessage();
}

public class MailMessage implements Message{

@Override
public Boolean sendMessage() {
return true;
}
}

public class SMSMessage implements Message{

@Override
public Boolean sendMessage() {
return true;
}
}

public class VoiceMessage implements Message{

@Override
public Boolean sendMessage() {
return true;
}
}


Referencias:
http://www.oodesign.com/open-close-principle.html
http://www.objectmentor.com/resources/articles/ocp.pdf
http://code.tutsplus.com/tutorials/solid-part-2-the-openclosed-principle--net-36600



sábado, 7 de marzo de 2015

¿Qué es Clean Code?

¿Qué es Clean Code?

En los últimos años en las empresas de desarrollo de Software se han estado adoptando procesos, metodologías y tecnologías que permitan que el desarrollo de sistemas sea mas dinámico y eficiente con la finalidad de tener sistemas mas confiables y robustos. Un punto importante en esta adaptación de metodologías es lo referente al proceso propio del desarrollo de Software, es decir, como hacer un código mantenible, legible, entendible, ...... ible.

El Clean Code mas que una metodología yo lo veo como una filosofía de trabajo, son las practicas que te permiten que el código que desarrollas sea realizado de una manera profesional y cumpla con ciertas características.

A continuación voy a listar algunas definiciones de Clean Code tomadas del libro Clean Code de Robert C. Martin. En cada definición se pueden ver puntos importantes para cada autor,  después de leer las definiciones tu puedes crear tu propia definición y ver que tan importante es adoptar técnicas que te permitan crean Clean Code.

Bjarne Stroustrup, Inventor de C++
Me gusta que el código sea elegante y eficiente. La lógica debería ser sencilla para hacer difícil el ocultar bugs, dependencias mínimas para facilitar mantenimiento, manejo de errores basado en una estrategia articulada y rendimiento optimo.

Grady Booch, autor de Análisis y Diseño orientado a objetos con aplicaciones.
Clean Code es simple y directo, el Clean Code se lee como una prosa bien escrita. Clean Code nunca oscurece las intenciones de los diseñadores, mas bien esta lleno de abstracciones y simples lineas de control.

"Big" Dave Thomas, fundador de OTI.
Clean Code  puede ser leido y mejorado por un desarrollador que no es el autor original, tiene pruebas unitarias  y de aceptación, tiene nombres significativos, provee una forma en lugar de varias formas de hacer una cosa, Tiene mínimas dependencias, y provee claras y mínimas API's.

Michael Feathers, Autor de Working Effectively with Legacy Code.
Yo podría listar todas las cualidades que yo he observado en Clean Code,  pero hay una cualidad general en todos los códigos, Clean Code siempre luce que fue escrito por alguien que tiene cuidado.No hay nada obvio que tu puedas hacer mejor.

Ward Cunningham, inventor de Wiki, inventor de Fit, co-inventor de eXtreme Programming.
Tu sabes que estas trabajando en Clean Code cuando cada rutina que tu lees es bastante mejor de lo que tu esperas. Tu puedes llamar esto código "hermoso"cuando el código hace ver al lenguaje como hecho para resolver el problema.

Tenemos suficientes definiciones para poder crear un propio criterio sobre lo que es el Clean Code, al fin de cuentas todo nos lleva a realizar un código  de manera profesional, teniendo en consideración que muy probablemente en un futuro quien escribe el código o algún otro desarrollador tendrá que realizar modificaciones, y este trabajo de cambio debe de ser lo suficientemente transparente, y con mínimo impacto en otras secciones del sistema.

En las próximas entradas nos enfocaremos en algunas técnicas de Clean Code. Por lo pronto tenemos la tarea de reflexionar que tan limpio es el código que actualmente estamos escribiendo.


Esta imagen refleja en gran medida como saber si estamos tratando con Clean Code, en un revisión de código, cuantos WTF ocurren.

Bibliografía:
Clean Code A Handbook of Agile Software craftsmanship, Robert C. Martin Series.