Principios SOLID en la Programación Orientada a Objetos

  • Time to read 1 minute
Principios SOLID

Los principios SOLID tuvieron su origen en marzo de 1995. Robert C Martin, también conocido como Uncle Bob creó una serie de artículos que derivaron en una de las piedras angulares de las buenas prácticas que todo desarrollador debería leer al menos una vez en su vida: Agile Software Development: Principles, Patterns and Practices. El objetivo de esos principios se mejorar la calidad y mantenibilidad del código mediante una mejora en la gestión de dependencias.

SOLID es el acrónimo formado por los 5 principios que lo conforman, y que son los siguientes:

  • Single Repsonsibility Principle, o Principio de Responsabilidad Única: cada clase debe tener una única responsabilidad, y nunca debería de haber más de una razón para que la clase cambie. Para ello, las clases deben ser pequeñas (Uncle Bob dice que no deberían ocupar más de una pantalla de código). Si una clase tiene un tamaño excesivo, debe dividirse en partes más pequeñas.
  • Open Closed Principle, o Principio Abierto/Cerrado: las clases deben estar abiertas para su extensión, pero cerradas para su modificación. Debería ser posible extender la funcionalidad de una clase, pero para ello no debería ser necesario su modificación. Para ello, las clases deberían tener miembros privados, y getters/setters para el acceso a esos datos (siempre que los datos deban exponerse, evidentemente). Se recomienda el uso de clases abstractas cuando sea posible.
  • Liskov Substitution Principle o Principio de Sustitución de Liskov: formulado por Barbara Liskov en 1998, dice que los objetos en un programa deberían ser reemplazables con instancias de sus subtipos sin alterar el correcto funcionamiento del mismo. Esto ocurre cuando una clase que hereda de otra viola la relación "es un". Por ejemplo, un coche "es un" vehículo cumple esta relación. Un coche "es un" gato incumple la relación.
  • Interface Segregation Principle o Principio de Segregación de la Interfaz: es preferible tener múltiples interfaces pequeñas específicas del cliente, a tener interfaces grandes de propósito general. De esta forma, se minimiza la dependencia entre los componentes.
  • Dependency Inversion Principle, o Principio de Inversión de la Dependencia: las abstracciones no deben depender de los detalles, sino que los detalles deben depender de las abstracciones. A pesar de estar íntimamente ligado, no se debe confundir con la Inyección de Dependencias. La Inyección de Dependencias es uno de los métodos que siguen este principio.