Está en la página 1de 4

Principios de diseño de software: Solid

Sebastián Felipe Almadana moreno 20172005076


Felipe.am.99@outlook.es

Resumen- Los principios de diseño del software pensamos "Ya que estamos aquí, para que
orientado a objetos son una herramienta que voy a crear una clase para realizar esto.
permite el desarrollo, la organización y y la Directamente lo pongo aquí".
orientación para crear aplicativos en lenguajes
orientados a objetos, Estos principios fueron El problema surge cuando tenemos la
definidos por Robert Martin (mejor conocido necesidad de utilizar ese mismo método
como el tío Bob). Su trabajo consistió en tomar las desde otra clase. Si no se reautoriza en ese
ideas de distintas personas de la industria, y momento y se crea una clase destinada para
unirlas bajo la sigla SOLID (cada letra representa la finalidad del método, nos toparemos a
un principio).
largo plazo con que las clases realizan tareas
Abstract- the solid principles are base don the que no deberían ser de su responsabilidad.
modularity of the object based programming,
there are more than this five solid principles, but
in this paper we are going to describe the five solid
principles and other 3 random software design
principles, every Word of the solid principles
represents one principle of the industry of the
programation.

Objetivo General
El objetivo de tener un buen diseño de II. O-Abierto Cerrado
programación es abarcar la fase de Este segundo principio nos dice que nuestro
mantenimiento de una manera más legible y sistema debería estar cerrado a
sencilla así como conseguir crear nuevas modificaciones, y abierto a extensiones. En
funcionalidades sin tener que modificar en pocas palabras: si queremos añadir nuevo
gran medida código antiguo. Los costes de código, lo ideal sería poder construir sobre lo
mantenimiento pueden abarcar el 80% de un que ya existe, sin tener que hacer
proyecto de software por lo que hay que modificaciones grandes. El uso más común
valorar un buen diseño. de extensión es mediante la herencia y la re
Palabras Claves implementación de métodos. Existe otra
alternativa que consiste en utilizar métodos
solid, software, orientado a objetos, modularidad, que acepten una interface de manera que
diseño podemos ejecutar cualquier clase que
Marco teórico implemente ese interface. En todos los casos,
el comportamiento de la clase cambia sin que
I. S- Responsabilidad Simple hayamos tenido que tocar código interno.
Este principio trata de destinar cada clase a
una finalidad sencilla y concreta. En
muchas ocasiones estamos tentados a poner
un método reutilizable que no tienen nada que
ver con la clase simplemente porque lo utiliza
y nos pilla más a mano. En ese momento
métodos que tener un interface con muchos
métodos.
El objetivo de este principio es
principalmente poder reaprovechar los
interfaces en otras clases. Si tenemos un
interface que compara y clona en el mismo
interface, de manera más complicada se podrá
utilizar en una clase que solo debe comparar
o en otra que solo debe clonar.
III. L-Sustitución de Liskov
Este principio nos habla específicamente de
la herencia. En pocas palabras, dice
que siempre deberíamos poder reemplazar
instancias de una clase padre por instancias
de una clase hija, sin que haya
comportamiento no deseados.
Visto de otra manera, las clases hijas no
deberían modificar o eliminar los
comportamientos definidos en el padre. A
diferencia de los principios anteriores, no hay
algún patrón de diseño específico por aplicar
V. D-Inversión de dependencias
aquí. Sin embargo, tener a la mano patrones
de diseño relacionados con la herencia puede Este principio tiene dos ideas importantes de
ser muy útiles. fondo: Los módulos de alto nivel no deberían
depender de módulos de bajo nivel, sino de
abstracciones. Las abstracciones no deberían
depender de los detalles. Los detalles
deberían depender de las abstracciones.
Una forma de lograr esto es empleando la
inyección de dependencias (un tipo
de inversión de control). Si bien no es uno de
los patrones de diseño orientado a objetos, es
una forma muy útil de garantizar la
dependencia con abstracciones. En general
IV. I- Segregación de la interface todos los patrones que ayuden a abstraer
nuestros módulos son útiles para lograr este
Este principio fue formulado por Robert C. principio. El objetivo de este principio es el
Martin y trata de algo parecido al primer uso de abstracciones para conseguir que una
principio. Cuando se definen interfaces estos clase interactúe con otras clases sin que las
deben ser específicos a una finalidad conozca directamente. Es decir, las clases de
concreta. Por ello, si tenemos que definir una nivel superior no deben conocer las clases de
serie de métodos abstractos que debe utilizar nivel inferior. Dicho de otro modo, no debe
una clase a través de interfaces, es preferible conocer los detalles. Existen diferentes
tener muchos interfaces que definan pocos patrones como la inyección de dependencias
que nos permiten invertir el control.
VI. Diseño por contrato

El diseño por contratos puede ser visto como


la aplicación a la construcción de software de
los contratos que rigen los asuntos de las
personas. Cuando dos personas establecen un
contrato se desprenden, de éste, las
obligaciones y beneficios de cada una. Este
tipo de contratos en software especifican, en
forma no ambigua, las relaciones entre las
rutinas y los llamadores de las mismas.
Podemos ver un sistema como un conjunto de
elementos de software interrelacionados, VIII. Ley de Deméter
donde cada uno de los elementos tiene un
objetivo con vistas a satisfacer las Según este principio, una unidad solo debe
necesidades de los otros. Dichos objetivos tener conocimiento limitado de otras
son los contratos. Los contratos deben unidades, y solo conocer aquellas que están
cumplir, por lo menos, con dos propiedades: relacionadas. La una unidad solo debe hablar
ser explícitos y formar parte del elemento de con amigos y nunca con extraños. Además la
software en sí mismo. El Diseño por unidad solo debe hablar con amigos
Contratos da una visión de la construcción de inmediatos.
sistemas como un conjunto de elementos de Simplificando mucho, tenemos que tratar de
software cooperando entre sí.
evitar utilizar métodos de un objeto que ha
sido devuelto por otro método. En este caso
es útil seguir la regla de nunca usar más de un
punto cuando accedemos a métodos de un
objeto.
IX. Conclusiones
Los principios de diseño de software son una
poderosa herramienta que usamos los
VII. Principio YAGNI programadores para poder organizar mejor la
Este principio parte de la idea que comparten información, poder hallar una solución al los
algunos programadores de “hacer las cosas problemas de la programación orientada a
por si acaso”, El principio YAGNI (You ain't objetos usando las diferentes reglas y criterios
gonna need it), viene a decir que no debemos que esta nos brinda y en general para
implementar algo si no estamos seguros de optimizar el funcionamiento de las
necesitarlo. Así ahorramos tiempo y esfuerzo. aplicaciones.
Bibliografía
- https://www.genbeta.com/desarroll
o/doce-principios-de-diseno-que-
todo-desarrollador-deberia-conocer
- https://www.genbeta.com/desarroll
o/solid-cinco-principios-basicos-de-
diseno-de-clases
- http://www.revista.unam.mx/vol.4/
num5/art11/art11.htm
- https://www.oscarblancarteblog.co
m/2018/08/15/principios-solid-
patrones-diseno/
- https://mvpcluster.com/diseno-de-
software-2/

También podría gustarte