20182020084 1

Principios De Diseño en la Programación

Orientada a Objetos (febrero de 2020)
Jackson Hendrich Luna Bonilla, Programación Avanzada, Ingeniería de
Sistemas, Facultad de Ingeniería, Universidad Distrital Francisco José de
Caldas

software se rompa). Bertrand Meyer es más explicito y

Resumen - Los principios de diseño en la P.O.O son el describe el principio relacionándolo con el manejo de clases:
núcleo de este paradigma de programación. “Deberías ser capaz de extender el comportamiento de una
Para ayudar a desarrollar programas robustos, mantenibles clase, sin modificarla”. Este principio esta intrínsecamente
y que se puedan modificar, existen varios principios de diseño relacionada a la descomposición modular, nuevamente
que ayudan a desarrollar software de este tipo; estos permiten Bertrand Meyer en su libro “Object Oriented Software
escribir un código limpio y flexible ante los cambios: que se Construction” describe: una técnica satisfactoria de
pueda modificar fácilmente según necesidad, que sea descomposición modular debe satisfacer un requisito más:
reutilizable y mantenible y promueven escalabilidad, es decir,
debe producir módulos que estén abiertos y cerrados:
que acepte ser ampliado con nuevas funcionalidades de manera
ágil.
El presente documento busca explicar los 5 principios • Un módulo está abierto si está disponible para la
SOLID y otros 3 principios indispensables si se piensa en un extensión. Por ejemplo, debería ser posible agregar
diseño de software óptimo. campos a las estructuras de datos que contiene, o
Abstract - The design principles in the O.O.P are the core of nuevos elementos al conjunto de funciones que
this programming paradigm. realiza.
To help develop robust, maintainable and modifiable • Un módulo está cerrado si está disponible para su uso
programs, there are several design principles that help to por otros módulos. Esto supone que el módulo ha
develop software of this type; These allow to write a clean and recibido una descripción bien definida y estable (l
flexible code in the face of changes: that it can be easily
ocultación de la información). En el caso de un
modified as needed, that it is reusable and maintainable and
promotes scalability, that is, accepting to be expanded with new
módulo de lenguaje de programación, un módulo
functionalities and adapting to them in an agile way. cerrado es uno que puede compilarse y almacenarse
This document seeks to explain the 5 SOLID principles and en una biblioteca, para que otros lo utilicen.
3 other essential principles for optimal software design.

III. PRINCIPIO DE RESPONSABILIDAD ÚNICA

I. INTRODUCCIÓN (SINGLE RESPONSIBILITY PRINCIPLE)

Es importante aprender los conceptos básicos de la “Una clase de tener una, y solo una, razón para cambiar”,
programación orientada a objetos, como la abstracción, la esto implica que una clase solo debe tener una funcionalidad
encapsulación, el polimorfismo y la herencia. Pero, al mismo (“responsabilidad”). El beneficio de este principio es que
tiempo, es igualmente importante conocer los principios de reduce el acoplamiento entre el componente individual del
diseño orientado a objetos. software y el Código.
En este sentido la aplicación de los principios SOLID está Por ejemplo, si se ubica más de una funcionalidad en una
muy relacionada con la comprensión y el uso de patrones de Clase en Java, esto provoca el acoplamiento entre dos
diseño, que nos permitirán mantener una alta cohesión y, por funciones, si cambia una funcionalidad, existe la posibilidad
tanto, un bajo acoplamiento de software. de que rompa la funcionalidad acoplada, lo que puede
ocasionar fallos y que se rompa el software.
II. PRINCIPIO ABIERTO-CERRADO (OPEN-CLOSED Robert C. Martin resume este principio en una frase:
PRINCIPLE) “Reúne las cosas que cambian por las mismas razones. Separa
aquellas que cambian por razones diferentes”.
Este principio enuncia: “Clases, métodos o funciones deben
ser abiertos para extensión (nueva funcionalidad) pero IV. INVERSIÓN DE DEPENDENCIAS (DEPENDENCY
cerrados para modificación”, el beneficio clave de este INJECTION OR INVERSION PRINCIPLE)
principio de diseño es que el código ya probado no se ve
afecta, lo que significa que no hay lugar para errores (que el
 20182020084 2

“Depende de abstracciones, no de clases concretas”. El los miembros no utilizados y reduciendo el acoplamiento en

objetivo del Dependency Inversion Principle consiste en consecuencia. Las interfaces más pequeñas son más fáciles de
reducir las dependencias entre los módulos del código, es implementar, mejorando la flexibilidad y la posibilidad de
decir, alcanzar un bajo acoplamiento de las clases. Rober C. reutilización. A medida que menos clases comparten estas
Martin enuncia: interfaces, se reduce el número de cambios necesarios en
respuesta a una modificación de la interfaz, lo que aumenta la
• Los módulos de alto nivel no deberían depender de robustez.
módulos de bajo nivel. Ambos deberían depender de
abstracciones.
• Las abstracciones no deberían depender de los VII. DRY (DON’T REPEAT YOURSELF)
detalles. Los detalles deberían depender de las
abstracciones. Este principio anuncia que no se debe escribir código
duplicado, en su lugar se debe usar la abstracción para abstraer
La idea es aislar nuestra clase detrás de un límite formado cosas comunes en un solo lugar. Si tiene un bloque de código
por las abstracciones de las que depende. Si todos los detalles en más de dos lugares, considere convertirlo en un método
detrás de esas abstracciones cambian, entonces nuestra clase separado, o si usa un valor codificado más de una vez, hágalo
aún está a salvo. Esto ayuda a mantener el acoplamiento bajo público (constante).
y hace que nuestro diseño sea más fácil de cambiar. También No hay que escribir código duplicado. El código duplicado
nos permite probar cosas de forma aislada. es propenso a generar errores y es difícil de mantener. Si estás
repartiendo código, extrae ese código a una función para
V. PRINCIPIO DE SUSTITUCION DE LISKOV (LISKOV encapsularlo. Si tenemos que hacer un cambio, éste estará
SUBSTITUTION PRINCIPLE) localizado en un solo lugar, y no desperdigado por todo el
código fuente.
Según el Principio de sustitución de Liskov, los subtipos Es recomendable dividir el código y lógica en unidades
deben ser sustituibles por el supertipo, Barbara Liskov reutilizables más pequeñas y usar ese código llamándolo
creadora de este principio dice que “las clases derivadas deben donde se desee.
poder sustituirse por sus clases base”. Esto es que los métodos Menos código es bueno: ahorra tiempo y esfuerzo, es fácil
o funciones que usan el tipo de superclase deben poder de mantener y también reduce las posibilidades de errores,
trabajar con el objeto de la subclase sin ningún problema. además que hace más sencillo el mantenimiento.
Este principio está estrechamente relacionado con el
principio de responsabilidad única y el principio de
segregación de interfaces. VIII. KISS (KEEP IT SIMPLE, STUPID)
Si una clase tiene más funcionalidad que la subclase, es
posible que no admita parte de la funcionalidad y viole este El principio KISS es descriptivo para mantener el código
principio. Para seguir este principio de diseño, la clase o simple y claro, lo que facilita su comprensión. Mantenga sus
subclase derivada debe mejorar la funcionalidad, pero no métodos pequeños. Cada método nunca debe tener más de 40-
reducirla. 50 líneas.
Según Robert C. Martin incumplir el Liskov Substitution Cada método solo debe resolver un pequeño problema, no
Principle implica violar también el principio de Abierto- muchos casos de uso. Si tiene muchas condiciones en el
Cerrado. método, divídalas en métodos más pequeños. No solo será más
fácil de leer y mantener, sino que puede ayudar a encontrar
errores mucho más rápido. Intenta escribir pequeños bloques
VI. PRINCIPIO DE SEGREGACIÓN DE INTERFACES
de código que hagan una sola tarea (Single responsibility
(INTERFACE SEGREGATION PRINCIPLE)
principle).

Robert C. Martin sugiere para este ultimo principio: “Haz

interfaces que sean específicas para un tipo de cliente”, el IX. FAVOR COMPOSITION OVER INHERITANCE
Principio de segregación de interfaz obliga a que un cliente no (FAVORECER LA COMPOSICIÓN SOBRE LA
debe implementar una interfaz si no la utiliza; es preferible HERENCIA)
contar con muchas interfaces que definan pocos métodos que
tener una interface forzada a implementar muchos métodos a Favorecer la composición sobre la herencia es un principio
los que no se les dará uso. de diseño que le da al diseño una mayor flexibilidad. Es más
Suele incumplirse este principio principalmente cuando una natural construir clases de dominio empresarial a partir de
interfaz contiene más de una funcionalidad, y el cliente solo varios componentes que tratar de encontrar puntos en común
necesita una funcionalidad y ninguna otra. entre ellos y crear un árbol genealógico. Por ejemplo, un pedal
Las clases y sus dependencias se comunican mediante acelerador y un volante comparten muy pocos rasgos
interfaces bien enfocadas, minimizando las dependencias de comunes, pero ambos son componentes vitales en un
 20182020084 3

automóvil. Lo que pueden hacer y cómo se pueden utilizar

para beneficiar al automóvil se define fácilmente. La
composición también proporciona un dominio comercial más
estable a largo plazo, ya que es menos propenso a las
peculiaridades de los miembros de la familia. En otras
palabras, es mejor componer lo que puede hacer un objeto que
extender lo que es.
El diseño inicial se simplifica identificando los
comportamientos de los objetos del sistema en interfaces
separadas en lugar de crear una relación jerárquica para
distribuir los comportamientos entre las clases de dominio
empresarial a través de la herencia. Este enfoque acomoda
más fácilmente los cambios de requisitos futuros que de otro
modo requerirían una reestructuración completa de las clases
de dominio empresarial en el modelo de herencia. Además,
evita problemas a menudo asociados con cambios
relativamente menores en un modelo basado en herencia que
incluye varias generaciones de clases.

X. CONCLUSIÓN

Cuando se desarrolle cualquier código o módulo, se debe

tener en cuenta los principios de diseño de software y usarlos
con el fin de tener un código dispuesto a la extensión,
mantenimiento y depuración, esto para evitar la frustración
que se evidencia frecuentemente cuando un código no es para
nada ordenado, limpio y mucho menos entendible. Es
recomendable convertirlos en un hábito para evitar tener que
preguntarse dónde está un método, porque una clase no hace
lo que tiene que hacer o porque cuando creo una instancia se
cambia el valor de una variable, la cual no debería hacerlo.
Ahorrará tiempo de desarrollo y hará que su módulo de
software sea robusto, lo que podría ser fácil de mantener y
ampliar.

X. REFERENCIAS

[1] Anónimo, “Composition over inheritance”, tomado de:

https://en.wikipedia.org/wiki/Composition_over_inheritance
[2] Anónimo, “SOLID Principles in Java Application Development”,
tomado de: https://www.jrebel.com/blog/solid-principles-in-java
[3] Arvind Singh Baghel, “Software Design Principles DRY and KISS”,
tomado de: https://dzone.com/articles/software-design-principles-dry-
and-kiss
[4] María José Martin, “SOLID: los 5 principios que te ayudarán a
desarrollar software de calidad”, tomado de:
https://profile.es/blog/principios-solid-desarrollo-software-calidad/
[5] Javin Paul, “Infrared navigation—Part I: An assessment of feasibility
(Periodical style), 10 OOP Design Principles Every Programmer Should
Know”, tomado de: https://hackernoon.com/10-oop-design-principles-
every-programmer-should-know-f187436caf65
[6] Robert C. Martin, “The Open Closed Principle”, tomado de:
https://blog.cleancoder.com/uncle-
bob/2014/05/12/TheOpenClosedPrinciple.html
[7] “Rubenfa”, “Doce principios de diseño que todo desarrollador debería
conocer”, tomado de: https://www.genbeta.com/desarrollo/doce-
principios-de-diseno-que-todo-desarrollador-deberia-conocer