SOLID

5 principios bsicos de la programacin orientada a objetos, explicados en Agile Software Development: Principles, Patterns, and Practices por uno de los grandes exponentes de la artesana del software, el famoso Uncle Bob (Robert C. Martin).

Por qu SOLID?

SOLID
SRP OCP LSP Single responsibility principle Open/closed principle Liskov substitution principle

ISP
DIP

Interface segregation principle

Dependency inversion principle

SINGLE RESPONSIBILITY PRINCIPLE (PRINCIPIO DE RESPONSABILIDAD NICA)

Cada componente, ya sean paquetes, clases, mtodos e incluso bloques de cdigo.

Debe tener una nica responsabilidad, ocuparse de una nica tarea. Aumentar de esa forma la cohesin y reducir el acoplamiento.

EJEMPLO
Tenemos una clase Pedido con dos mtodos: cargar y calcularCosto. Ambos mtodos se encargan de cosas relacionadas con los pedidos. La realidad es que la clase se encarga de tareas relacionadas con los pedidos y de tareas relacionadas con la base de datos.

OPEN CLOSED PRINCIPLE (PRINCIPIO ABIERTO/CERRADO)

Todo componente debe estar abierto a nuevas funcionalidades, pero cerrado a cambios en su cdigo. Cmo hacerlo? Mediante la abstraccin, por ejemplo, el polimorfismo.

tengo una clase Archivo con un mtodo reproducir,

Switch que llama a un mtodo u otro de la clase dependiendo de si el archivo es un MP3 o WMA. Si quiero aadir un nuevo formato ms tarde, tendr que modificar el Switch.

Lo recomendable es Definimos reproducir como abstracto y movemos la implementacin a varias clases hijas. cuando queramos aadir un nuevo formato, slo necesitaremos crear una nueva clase hija.

https://gist.github.com/2896236#file_ocp_empleados.sin_refactorizar.cs

https://gist.github.com/2896236#file_ocp_empleados.refactorizado.cs

LISKOV SUBSTITUTION PRINCIPLE (PRINCIPIO DE SUSTITUCIN DE LISKOV)

https://gist.github.com/2896064

https://gist.github.com/2896078

INTERFACE SEGREGATION PRINCIPLE (PRINCIPIO DE SEGREGACIN DE INTERFACES)

Crea pequeas interfaces especficas para los clientes. Otra forma de expresarlo es que las clases que implementen una interfaz o una clase abstracta, no deberan estar obligadas a implementar mtodos que no utilizan. No sera una gran idea crear un mtodo fotografriar() en la clase padre.
este diseo slo servira para crear confusin y dificultar el mantenimiento.

Ejemplo: una clase abstracta TelefonoMovil.

Aunque la implementacin del mtodo en la clase concreta consistiera en no hacer nada.

o lanzar una excepcin.

https://gist.github.com/2896112#file_lsp_animal.sin_refactorizar.cs

https://gist.github.com/2896112#file_lsp_animal.refactorizado.cs

DEPENDENCY INVERSION PRINCIPLE (PRINCIPIO DE INVERSIN DE DEPENDENCIAS)

Depende de abstracciones, no de implementaciones concretas. Se llama as porque, al contrario de lo que sucede a veces, las clases concretas deberan depender de clases abstractas, y no a la inversa. Una clase que se encargar de gestionar la configuracin de la aplicacin. una clase que permite leer y escribir de un archivo de texto plano. Pero, y si de repente decidimos que queremos utilizar una base de datos?

Definicin

Ejemplo

Lo ideal

Nuestra clase utilizara una clase abstracta o una interfaz.

En lugar de una implementacin concreta, como era la clase para trabajar con archivos de texto plano.

https://gist.github.com/2896132#file_dip_hola_mundo.sin_refactoriza r.cs

https://gist.github.com/2896132#file_dip_hola_mundo.refactorizado. cs

Referencias
http://www.slideshare.net/jrhuerta/principios-solid-dediseo-orientado-a-objetos http://www.genbetadev.com/paradigmas-deprogramacion/solid-cinco-principios-basicos-de-diseno-declases http://mundogeek.net/archivos/2011/06/09/principiossolid-de-la-orientacion-a-objetos/ http://www.fjordan.es/solid-principios-basicos-de-disenode-clases.html http://elblogdelfrasco.blogspot.com/2012/03/solid-los-5principios-fundamentales-de.html http://en.wikipedia.org/wiki/SOLID_%28objectoriented_design%29