Hace un par de semanas he comenzado a leer sobre Diseño Ágil con TDD (Test Driven Development) de Carlos Blé Jurado. Un libro con bastante ejemplos sobre TDD – Desarrollo Dirigido por Pruebas él cual recomiendo darle una lectura e introducirnos al Desarrollo Ágil con TDD.

En el cápitulo de Diseño Orientado a Objetos se describe la gran importancia de los principios de diseño orientado a objetos en términos de la gestión de dependencias  –  SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion), los cuales fueron introducidos por Robert C. Martin en 1995. Estos principios son los siguientes:

Principio de Única Responsabilidad – Single Responsibility Principle (SRP)

Cada clase debería tener un único motivo para ser modificada. Si estamos delante de una clase que se podría ver obligada a cambiar ante una modificación en la base de datos y a la vez, ante un cambio en el proceso de negocio, podemos afirmar que dicha clase tiene más de una responsabilidad o más de un motivo para cambiar. Se aplica tanto a clases como a cada uno de sus métodos.

Principio Abierto/Cerrado – The Open Closed Principle (OCP)

Una entidad software (una clase, módulo o función) debe estar abierta a extensiones pero cerrada a modificaciones.  el comportamiento de una entidad debe poder ser alterado sin tener que modificar su propio código fuente.  El nombre de Open-Closed se debe a Bertrand Meyer en 1998.

Principio de Sustitución de Liskov – Liskov Substitution Principle (LSP)

Introducido por Barbara Liskov en 1987. Si una función recibe un objeto como parámetro, de tipo X y en su lugar le pasamos otro de tipo Y, que hereda de X, dicha función debe proceder correctamente por el propio polimorfismo existente. El diseño por contrato (Design by Contract) es otra forma de llamar al LSP.

Principio Segregación de Interfaz – Interface Segregation Principle (ISP)

No obliguemos a los clientes a depender de clases o interfaces que no necesitan usar.  Tal imposición ocurre cuando una clase o interfaz tiene más métodos de los que un cliente (otra clase o entidad) necesita para sí mismo.

Principio de Inversión de Dependencias – Dependency Inversi´on Principle (DIP)

DIP explica que un módulo concreto A, no debe depender directamente de otro módulo concreto B, sino de una abstracción de B. Tal abstracción es una interfaz o una clase (que podría ser abstracta) que sirve de base para un conjunto de clases hijas.

Estos principios describen principalmente la gestión de dependencias entre clases, algo que no se ocupa el modelado tradicional ya que pone más énfasis en la conceptualización de clases.

Saludos!