Principios S.O.L.I.D.
Paola Natasha Becerra Marquez.
Bogota - Colombia,
Universidad Distrital Francisco Jose de Caldas.
paonata_marquez@outlook.com.
Resumen- En este documento se presentara
una compilación de los principios de diseño
SOLID, acompañado de un análisis detallado
sobre cada uno de ellos; de la misma forma se
añadirán dos principios de diseño distintos a los
SOLID para completar la selección, los cuales
seran DRY y KISS. El objetivo principal de esta
agrupación es evaluar la importancia de cada
uno de ellos en la construcción de un producto
de software robusto y funcional.
Palabras Clave- diseño, software, SOLID.
INTRODUCCIÓN
Las aplicaciones de software se desarrollan
contemplando ciertas funcionalidades, sin embargo,
nada impide que en el futuro sea necesario
modificar alguna de ellas o simplemente agregar
otras; es por esta razón que los desarrolladores se
ven obligados a contemplar ciertos principios
básicos del diseño, de esta forma, en el futuro no
será tan complejo modificar o añadir acciones en
nuestro programa de aplicación.
DESARROLLO DEL TEMA
Los principios SOLID son cinco, uno por cada
letra, se agrupan de esta forma gracias a Robert C
Martin, quien acuño este acrónimo en el año 1995.
Principio de responsabilidad única (Single
responsibility): Este principio da origen a la letra S
de S.O.L.I.D. Se rige por la idea de que cada clase
debe tener “una única responsabilidad”, es decir,
una clase debe tener una única razón para ser
modificada; esto también aplica para los métodos,
cada método debería tener una única razón para ser
modificado. El efecto que produce este principio
son clases con nombres muy descriptivos y por
tanto largos, que tienen menos de cinco métodos,
cada uno también con nombres, que sirven
perfectamente de documentación, es decir, de varias
palabras: CalcularAreaRectangulo y que no
contienen más de 15 líneas de código.
Principio abierto-cerrado (Open-closed): “Una
entidad de software debe estar abierta a extensiones,
pero cerrada a modificaciones”. Los programas de
aplicaciones generalmente requieren cambios,
además, es común que las entidades dependan de
otras, por lo tanto, las modificaciones en el código
pueden causar efectos colaterales en todo el
programa; es por ello que existe este principio, de
forma resumida lo que propone el enunciado es que
el comportamiento de una entidad debe poder ser
alterado sin tener que modificar su propio código
fuente. El uso más común de extensión es mediante
la herencia y la reimplementación de métodos.
Existe otra alternativa que consiste en utilizar
métodos que acepten una interface de manera que
podemos ejecutar cualquier clase que implemente
esa interface. En todos los casos, el comportamiento
de la clase cambia sin que hayamos tenido que tocar
código interno.
Liskov Substitution Principle (LSP): Este
principio propone que, 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. En síntesis, el
principio describe la importancia de crear todas las
clases derivadas para que también puedan ser
tratadas como la propia clase base. Cuando creamos
clases derivadas debemos asegurarnos de no
reimplementar métodos que hagan que los métodos
de la clase base no funcionases si se tratasen como
un objeto de esa clase base.
Interface Segregation Principle (ISP): Cuando
empleamos el “Principios de responsabilidad única”
también empleamos el ISP como efecto colateral.
 El ISP defiende que 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.
Seguramente sirve a varios objetos cliente con
responsabilidades diferentes, con lo que debería
estar dividida en varias entidades. Es decir: cuando
se definen interfaces estos deben ser específicos a
una finalidad concreta. Por ello, si tenemos que
definir una serie de métodos abstractos que debe
utilizar una clase a través de interfaces, es preferible
tener muchas interfaces que definan pocos métodos
que tener una interface con muchos métodos. El
objetivo de este principio es principalmente poder
reaprovechar las interfaces en otras clases.
Dependency Inversión 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. El
objetivo de este principio es conseguir desacoplar
las clases con el uso de abstracciones para conseguir
que una clase interactúe con otras clases sin que las
conozca directamente. En todo diseño siempre debe
existir un acoplamiento, pero hay que evitarlo en la
medida de lo posible. Un sistema no acoplado no
hace nada, pero un sistema altamente acoplado es
muy difícil de mantener.
DRY: No hay que escribir código duplicado. El
código duplicado es propenso a generar errores y es
difícil de mantener. Si estamos repitiendo código,
los más recomendable es extraer ese código a una
función para encapsularlo. De esta manera si
tenemos que hacer un cambio, este estará localizado
en un solo punto, y no desperdigado por todo el
código fuente.
KISS (Keep It Simple Stupid): El diseño de un
programa debe ser sencillo. Cuánto más sencillo
sea, mejor. Hay que evitar la complejidad como
norma general, pero sobre todo la complejidad
innecesaria.
CONCLUSIONES
Cuando desarrollamos aplicaciones o productos
de software estamos entregando un aplicativo que
esta contemplado para usarse no solamente un día, o
una semana, sino un tiempo prolongado; de esta
manera se hace pertinente construir aplicaciones
robustas que permitan modificaciones o
extensiones en el futuro, pues es muy probable que
se necesiten. Para llevar a cabo esta complicada
tarea, es necesario valerse de diseños o estructuras
ya establecidas, como lo son los principios de
diseño de software expuestos en el presente
documento.
REFERENCIAS
[1] Durango, A. (2014). Diseño de Software. IT
Campus Academy.