Nombre:

Dorian Sirí

Matrícula:

2021-2139

Asignatura:

Programación II.

Maestro:

Michael Grullón

Cuatrimestre:

2023
 Cohesión:
La cohesión es uno de los principios sólidos fundamentales en la
programación orientada a objetos (POO). Se refiere al grado en que los
componentes de una clase (como atributos y métodos) están relacionados y
trabajan juntos de manera lógica y cohesionada para cumplir con una
responsabilidad específica

La cohesión se considera una característica deseable en la POO porque

conduce a un diseño de software más claro, mantenible y fácil de entender.
Cuando una clase exhibe una alta cohesión, significa que sus miembros están
estrechamente relacionados entre sí y trabajan juntos para realizar una tarea
específica. Esto tiene varias ventajas:

1. Facilita la comprensión del código: Un diseño cohesivo hace que sea

más fácil entender cómo funciona una clase y cuál es su propósito.

2. Facilita el mantenimiento: Los cambios o actualizaciones en una clase

cohesiva tienden a ser más localizados y menos propensos a tener
efectos secundarios inesperados en otras partes del programa.

3. Fomenta la reutilización: Las clases cohesionadas suelen ser más

reutilizables en diferentes partes de una aplicación o incluso en
proyectos diferentes.

4. Mejora la modularidad: Una alta cohesión a menudo implica que las

clases se dividen en unidades más pequeñas y específicas, lo que
mejora la modularidad del software.

Por otro lado, una baja cohesión se refiere a una clase que tiene miembros que
no están relacionados de manera lógica o que realizan múltiples tareas
diferentes. Esto puede llevar a un diseño confuso y difícil de mantener.
 Acoplamiento:

El acoplamiento es uno de los principios fundamentales del diseño de

software sólido, que es una serie de principios de diseño orientados a objetos
destinados a crear software más mantenible, escalable y robusto. En el
contexto de los principios SOLID, el acoplamiento se relaciona
específicamente con el principio "D" de SOLID, que es el principio de
Inversión de Dependencias (Dependency Inversion Principle, DIP).

El principio de Inversión de Dependencias (DIP) establece que:

1. Los módulos de alto nivel no deben depender de los módulos de bajo
nivel. Ambos deben depender de abstracciones.

2. Las abstracciones no deben depender de los detalles. Los detalles deben

depender de las abstracciones.

En otras palabras, este principio promueve la reducción del acoplamiento

entre los diferentes componentes de un sistema de software al introducir
abstracciones o interfaces que actúan como capas intermedias. Estas
abstracciones permiten que los componentes de alto nivel y los de bajo nivel
interactúen a través de interfaces en lugar de depender directamente unos de
otros.
El objetivo del principio de Inversión de Dependencias es disminuir el
acoplamiento y aumentar la flexibilidad y la reusabilidad del código. Al seguir
este principio, se puede lograr un diseño más modular y una mayor capacidad
para realizar cambios en el software sin afectar a otras partes del sistema.

El objetivo al diseñar un sistema de software es lograr un equilibrio adecuado

entre cohesión y acoplamiento. Es decir, se busca maximizar la cohesión
dentro de los componentes (para que realicen tareas específicas de manera
efectiva) mientras se minimiza el acoplamiento entre ellos (para reducir la
interdependencia y la complejidad). Un diseño bien equilibrado promueve la
modularidad, la legibilidad y la mantenibilidad del código.
 SRP:
El Principio de Responsabilidad Única (Single Responsibility Principle, SRP)
es uno de los cinco principios del SOLID, que son un conjunto de principios
de diseño de software orientado a objetos destinados a crear software más
mantenible y escalable. El SRP se centra en la cohesión de las clases y
componentes de un sistema de software.
El SRP establece lo siguiente:
"Una clase debe tener una, y solo una, razón para cambiar."
En otras palabras, el SRP enfatiza que una clase o módulo debe tener una
responsabilidad única y bien definida en el sistema. Esto significa que una
clase no debe estar sobrecargada con múltiples responsabilidades o tareas
diferentes. En lugar de eso, debe haber una separación clara de
responsabilidades, de modo que, si hay un cambio en una de las
responsabilidades, no afecte las otras responsabilidades de la clase.
Beneficios del SRP:
1. Mantenibilidad: Cuando una clase tiene una única responsabilidad, es
más fácil entender, modificar y mantener.
2. Reutilización: Las clases con responsabilidades únicas son más
propensas a ser reutilizadas en diferentes partes de una aplicación o en
otros proyectos.
3. Testabilidad: Las clases con una única responsabilidad son más fáciles
de probar de forma aislada, lo que facilita las pruebas unitarias.

Ejemplo: Supongamos que tienes una clase que gestiona la lógica de

autenticación de usuarios y al mismo tiempo maneja la generación de
informes. Esta clase no sigue el SRP, ya que tiene dos responsabilidades
diferentes. Sería más adecuado dividir esta clase en dos: una para la
autenticación de usuarios y otra para la generación de informes.
 OCP:
El Principio de Abierto/Cerrado (Open/Closed Principle, OCP) es uno de los
cinco principios SOLID de diseño de software orientado a objetos. Fue
formulado por Bertrand Meyer en 1988 y se centra en la extensibilidad del
código sin modificar su comportamiento existente. El OCP se define de la
siguiente manera:
"Una entidad de software (clase, módulo, función, etc.) debe estar abierta para
su extensión pero cerrada para su modificación."
Esto significa que una vez que se ha escrito una entidad de software (como
una clase), no debería ser necesario modificarla cada vez que se desee agregar
nuevas funcionalidades o comportamientos. En cambio, el código debe ser
extensible mediante la adición de nuevas clases, módulos o funciones que se
conecten a la entidad existente.
Al seguir el OCP, se obtienen varios beneficios:
1. Mantenimiento más sencillo: No es necesario modificar el código
existente, lo que reduce el riesgo de introducir errores y simplifica el
mantenimiento.
2. Reutilización de código: Se fomenta la reutilización de clases y
componentes existentes en lugar de tener que modificarlos para
adaptarlos a nuevos requisitos.
3. Escalabilidad: El código se vuelve más escalable, ya que se pueden
agregar nuevas funcionalidades sin afectar el código existente.
4. Pruebas más sencillas: Las pruebas de unidades y la verificación de que
el comportamiento existente no se ve afectado son más sencillas.
Para cumplir con el OCP, es común utilizar técnicas como la herencia, la
implementación de interfaces y el uso de patrones de diseño, como el patrón
de estrategia o el patrón de decorador. Estas técnicas permiten agregar nuevas
funcionalidades al código existente sin modificarlo.
 LSP:
El Principio de Sustitución de Liskov (Liskov Substitution Principle, LSP) es
uno de los cinco principios SOLID de diseño de software orientado a objetos.
Fue formulado por Barbara Liskov en 1987 y se centra en la relación entre las
clases y subclases en la herencia de objetos. El LSP se define de la siguiente
manera:
"Las subclases deben ser sustituibles por sus clases base sin afectar la
integridad del programa."
En otras palabras, si una clase base (superclase) tiene un comportamiento
específico y se espera que las subclases sigan ese comportamiento, entonces
las subclases deben poder sustituirse por la clase base sin que ello cause
problemas en el programa.
Para cumplir con el LSP, se deben seguir ciertas reglas:
1. Los objetos de las subclases deben comportarse de manera coherente
con los objetos de la clase base. Esto significa que las subclases no
deben alterar el comportamiento predefinido de la clase base, sino que
deben extenderlo o especializarlo.
2. Las subclases pueden agregar comportamiento adicional, pero no deben
reemplazar o eliminar el comportamiento de la clase base. Esto asegura
que las subclases mantengan al menos el mismo nivel de funcionalidad
que la clase base.
3. Las excepciones lanzadas por las subclases no deben ser más
restrictivas que las excepciones lanzadas por la clase base. Esto
significa que si la clase base lanza ciertas excepciones, las subclases no
deben lanzar excepciones más restrictivas o específicas que limiten el
uso de las subclases.
Cumplir con el LSP promueve la coherencia en el diseño de clases y
subclases, y garantiza que las subclases sean verdaderamente sustituibles por
las clases base en todas las circunstancia
 ISP:

El Principio de Segregación de Interfaces (Interface Segregation Principle,

ISP) es uno de los cinco principios SOLID de diseño de software orientado a
objetos. Fue formulado por Robert C. Martin y se enfoca en la organización
de interfaces en las clases y la minimización de la dependencia de interfaces
no utilizadas. El ISP se define de la siguiente manera:
"Los clientes no deben verse obligados a depender de interfaces que no usan."
En otras palabras, una clase no debería tener que implementar métodos que no
necesita debido a una interfaz generalizada. En lugar de tener interfaces
grandes y genéricas, el ISP sugiere que las interfaces deberían ser más
específicas y divididas, de modo que las clases solo implementen las partes de
la interfaz que son relevantes para ellas.
Cumplir con el ISP tiene varios beneficios:
1. Reducción de acoplamiento: Las clases no están obligadas a depender
de funcionalidades innecesarias, lo que reduce el acoplamiento y hace
que el código sea más modular y mantenible.
2. Mayor cohesión: Las interfaces más específicas tienden a agrupar
métodos relacionados de manera coherente, lo que mejora la cohesión y
la claridad del diseño.
3. Facilita la reutilización: Las interfaces más pequeñas y específicas son
más fáciles de reutilizar en diferentes contextos, ya que no arrastran
funcionalidad no deseada.
4. Facilita las pruebas: Las clases pueden ser probadas más fácilmente si
solo implementan las partes de la interfaz que son relevantes para sus
pruebas.
Un ejemplo común de aplicación del ISP es dividir una interfaz monolítica en
múltiples interfaces más pequeñas y específicas. Esto permite que las clases
implementen solo las interfaces que necesitan para su funcionalidad, en lugar
de implementar una interfaz grande con métodos no utilizados.
 DIP:
El Principio de Inversión de Dependencias (Dependency Inversion Principle,
DIP) es uno de los cinco principios SOLID de diseño de software orientado a
objetos. Este principio fue formulado por primera vez por Robert C. Martin y
se centra en cómo las dependencias deben gestionarse en un sistema de
software. El DIP se define de la siguiente manera:
"Los módulos de alto nivel no deben depender de los módulos de bajo nivel.
Ambos deben depender de abstracciones. Además, las abstracciones no deben
depender de los detalles. Los detalles deben depender de las abstracciones."
Este principio se puede dividir en dos partes:
1. Abstracciones: En lugar de que los módulos de alto nivel dependan
directamente de los módulos de bajo nivel, ambos deben depender de
abstracciones. Las abstracciones son interfaces o clases base que
definen un conjunto de métodos o funciones comunes que pueden ser
implementados por los módulos de bajo nivel.
2. Detalles y concreciones: Los detalles de implementación y las clases
concretas deben depender de las abstracciones, no al revés. Esto
significa que las clases de alto nivel deben interactuar con las
abstracciones y no deben conocer los detalles de implementación de las
clases de bajo nivel.
El DIP promueve varios beneficios:
1. Desacoplamiento: Al utilizar abstracciones, se reduce el acoplamiento
entre los módulos de alto y bajo nivel, lo que hace que el sistema sea
más flexible y mantenible.
2. Reemplazo fácil: La inversión de dependencias permite reemplazar
módulos de bajo nivel por otros que cumplan con las mismas
abstracciones sin afectar a los módulos de alto nivel.
3. Pruebas unitarias: Facilita la escritura de pruebas unitarias, ya que se
pueden utilizar abstracciones para crear simulaciones o mockups de
módulos de bajo nivel.
4. Reutilización: Las abstracciones promueven la reutilización de código,
ya que múltiples módulos de bajo nivel pueden implementar las mismas
abstracciones.
Un ejemplo común del DIP es el uso de interfaces en lugar de clases concretas
en la programación orientada a objetos. Los módulos de alto nivel dependen
de interfaces (abstracciones), y las clases concretas (detalles de
implementación) dependen de esas mismas interfaces.