Principios SOLID de la orientacin a objetos

Los requisitos cambian. Es algo con lo que todos tenemos que lidiar cada da. De esto se desprende que, independientemente del tiempo que hayas invertido en la captura de requisitos y de las muchas funcionalidades extra que hayas podido implementar (en contra de lo que dicta YAGNI), tu aplicacin va a tener que cambiar. Ser mejor que ests preparado ello. Una forma de estarlo es seguir los 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) Estos principios, cuyas primeras letras forman el acrnimo mnemotcnico SOLID (slido), son los siguientes:

Single Responsibility Principle (Principio de Responsabilidad nica)

Cada componente, ya sean paquetes, clases, mtodos e incluso bloques de cdigo, debera tener una nica razn para cambiar. Esto es, debe tener una nica responsabilidad, ocuparse de una nica tarea, para aumentar de esa forma la cohesin y reducir el acoplamiento. Supongamos que tenemos una clase Pedido con dos mtodos: cargar, que traera de la base de datos la informacin del pedido y de los productos que lo componen, y calcularCoste, que simplemente sumara el precio de los productos, aplicando cualquier descuento pertinente. Esto podra parecer un buen diseo, porque, al fin y acabo, ambos mtodos se encargan de cosas relacionadas con los pedidos, pero 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. Queremos extender el comportamiento del componente sin modificar su cdigo. Cmo hacerlo? Mediante la abstraccin, por ejemplo, el polimorfismo. Supongamos que estoy programando un reproductor de audio, y tengo una clase Archivo con un mtodo reproducir, que consiste en un switch que llama a un mtodo u otro de la

clase dependiendo de si el archivo es un MP3, un WMA o un OGG. Si quiero aadir un nuevo formato ms tarde, tendr que modificar el switch, aadiendo una nueva expresin que llame a otra funcin. Si en lugar de utilizar un switch definimos reproducir como abstracto, y movemos la implementacin a varias clases hijas, una por cada formato, cuando queramos aadir un nuevo formato, slo necesitaremos crear una nueva clase hija.

Liskov Substitution Principle (Principio de Sustitucin de Liskov)

Los objetos de una clase deberan poder sustituirse por instancias de las clases derivadas. Llamado as porque fue enunciada por primera vez por Barbara Liskov, premio Turing 2008, puede servirnos para determinar si nuestra jerarqua se ajusta al Principio Abierto/Cerrado. El ejemplo tpico es una clase Cuadrado que hereda de una clase Rectangulo. El ancho y alto de ambas clases se encapsulan mediante mtodos get y set, pero en el caso del cuadrado, ambos mtodos modifican ambos atributos, de forma que ambas dimensiones coincidan, como es de esperar para un cuadrado. Ahora bien, si el cdigo cliente necesita saber con qu tipo est tratando para poder funcionar y responder adecuadamente, esto viola claramente el Principio Abierto/Cerrado.

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. Supongamos que tenemos una clase abstracta TelefonoMovil con la que queremos representar tanto mviles actuales como viejas reliquias. No sera una gran idea crear un mtodo fotografiar() en la clase padre, dado que no todos los telfonos tienen esta funcionalidad. Aunque la implementacin del mtodo en la clase concreta consistiera en no hacer nada o lanzar una excepcin, este diseo slo servira para crear confusin y dificultar el mantenimiento.

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.

Supongamos que tenemos una clase que se encargar de gestionar la configuracin de la aplicacin, y esta utiliza (tiene una dependencia de) 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? o un archivo XML? Lo ideal sera que 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.