SOLID by Samuel Reyes https://padlet.com/poo510/fzbdqlb1772iwwb6 Principios SOLID en-us 2023-06-29 04:16:36 UTC 2023-07-06 15:48:23 UTC hello@padlet.com Segregación De Interfaces samucoreyes https://padlet.com/poo510/fzbdqlb1772iwwb6/wish/2634854208
El principio de segregación de interfaces, establece que "los clientes no deben ser forzados a depender de interfaces que no utilizan". En otras palabras, este principio promueve la idea de dividir interfaces grandes y poco cohesivas en interfaces más pequeñas y específicas, de modo que los clientes solo dependan de las interfaces que realmente necesitan. La razón detrás de este principio es evitar la creación de interfaces sobrecargadas o monolíticas que obliguen a las clases o módulos a depender de funcionalidades innecesarias o irrelevantes para su contexto. Si una interfaz es demasiado grande, puede llevar a una mayor dependencia y acoplamiento innecesario entre los componentes del sistema.

Al aplicar el principio de segregación de interfaces, se busca diseñar interfaces cohesivas y enfocadas en un conjunto específico de responsabilidades. Esto permite que los clientes implementen solo las interfaces relevantes para ellos y evita que se vean afectados por cambios en otras partes del sistema.



]]> 2023-06-29 04:19:25 UTC https://padlet.com/poo510/fzbdqlb1772iwwb6/wish/2634854208 Principio de Abierto/Cerrado wamedinacarrion https://padlet.com/poo510/fzbdqlb1772iwwb6/wish/2634890849 Se refiere a un principio de diseño de software que promueve la extensibilidad y la modularidad del código.

En otras palabras, cuando se aplica el principio de abierto/cerrado, se busca diseñar componentes de software de manera que puedan ser extendidos o mejorados sin tener que modificar el código existente.

Una de la técnica más usada para este principio es el polimorfismo, en el cual se utiliza herencia e interfaces, se puede definir una estructura base común para las entidades y luego extenderlas con comportamientos específicos sin modificar la estructura base.]]> 2023-06-29 05:08:16 UTC https://padlet.com/poo510/fzbdqlb1772iwwb6/wish/2634890849 Principio de Sustitución de Liskov https://padlet.com/poo510/fzbdqlb1772iwwb6/wish/2634891588 El principio de sustitución de Liskov establece que si una clase A es un subtipo de una clase B, entonces los objetos de tipo B pueden ser reemplazados por objetos de tipo A sin alterar el comportamiento del programa.]]> 2023-06-29 05:09:06 UTC https://padlet.com/poo510/fzbdqlb1772iwwb6/wish/2634891588 El principio de Responsabilidad Unica https://padlet.com/poo510/fzbdqlb1772iwwb6/wish/2635255288
El principio de responsabilidad única (SRP) es un principio de diseño de software que establece que cada módulo, clase o función debe tener una única responsabilidad o tarea. Al aplicar este principio, se logra un código más cohesivo, con menos acoplamiento y más fácil de mantener. Cada componente se enfoca en una única tarea y no tiene conocimiento de las demás responsabilidades del sistema. Esto facilita el mantenimiento, la reutilización y la comprensión del código, y también mejora la escalabilidad y las pruebas unitarias. En resumen, el SRP promueve la creación de componentes de software más claros y eficientes al asignarles una única responsabilidad. 

Un ejemplo de SRP es: 

  1. Gestión de usuarios: Una clase o módulo que se encarga únicamente de la creación, autenticación y gestión de usuarios en un sistema. No debe tener la responsabilidad de realizar operaciones relacionadas con la lógica de negocios o el procesamiento de datos.

]]> 2023-06-29 15:42:17 UTC https://padlet.com/poo510/fzbdqlb1772iwwb6/wish/2635255288 El principio de inversión de la dependencia https://padlet.com/poo510/fzbdqlb1772iwwb6/wish/2635269326 En el diseño orientado a objetos, el principio de inversión de dependencia es una forma específica de desacoplar módulos de software. Al seguir este principio, las relaciones de dependencia convencionales establecidas desde los módulos de alto nivel de establecimiento de políticas a los módulos de dependencia de bajo nivel se invierten, lo que hace que los módulos de alto nivel sean independientes de los detalles de implementación del módulo de bajo nivel. El principio establece: 

-Los módulos de alto nivel no deberían depender de los módulos de bajo nivel. Ambos deberían depender de abstracciones (p.ej., interfaces).
-Las abstracciones no deberían depender de los detalles. Los detalles (implementaciones concretas) deben depender de abstracciones.
Módulos de alto nivel: se refieren a los objetos que definen el qué es y qué hace tu programa. Aquellos que contienen la lógica de negocio y cómo interactúa el software entre sí. Son los objetos más importantes del programa. Por ejemplo, en una aplicación de un banco, podría ser el objeto que se encarga de devolver la lista de cuentas bancarias.
Módulos de bajo nivel: son aquellos objetos que no están directamente relacionados con la lógica de negocio del programa. Por ejemplo, el mecanismo de persistencia (CoreData, Realm, MySQL, etc…) o el mecanismo de acceso a red (URLSession, Alamofire, AFNetworking, etc…). Son objetos menos importantes, de los cuales no depende la lógica de negocio.
Abstracciones: se refieren a Tipos de Datos que no son las implementaciones concretas, si no los que definen la interfaz pública. Serán, por tanto, protocolos (o interfaces) o clases abstractas (*en Swift no existen las clases abstractas como tal)]]> 2023-06-29 16:13:01 UTC https://padlet.com/poo510/fzbdqlb1772iwwb6/wish/2635269326