Principios SOLID: Single Responsibility Principle

El principio de responsabilidad única (también conocido como “la lata cohesión”) nos dice que una clase debería tener un único objetivo, muy claro, muy conciso y muy acotado.
.
La idea es evitar que una sola clase haga muchas cosas en lo que podría compararse con un “hombre orquesta”.

Este principio no solo se aplica a las clases, igual se aplica a las funciones, ¿Alguna vez has escuchado decir “una función debe hacer una única tarea”? Pues ahora sabes por qué

Principio de responsabilidad única:

• Una clase debería tener sólo una razón para cambiar
• Cada responsabilidad es el eje del cambio
• Para contener la propagación del cambio, debemos separar las responsabilidades.
• Si una clase asume más de una responsabilidad, será más sensible al cambio.
• Si una clase asume más de una responsabilidad, las responsabilidades se acoplan.

Los 5 principios SOLID de diseño son:

S: Single Responsibility Principle (SRP)

O: Open/Closed Principle (OCP)

L: Liskov Substitution Principle (LSP)

I: Interface Segregation Principle (ISP)

D: Dependency Inversion Principle (DIP)

Principios SOLID: Single Responsibility Principle

Solid es un acrónimo en inglés que hace referencia 5 principios básicos de OOP, su objetivo es apuntar a desarrollar aplicaciones fácilmente mantenible a lo largo del tiempo.

Los 5 principios son:

• Single Responsibility Principle
• Open/closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inevrsion Principle

Single Responsibility Principle

El principio de responsabilidad única nos dice que una clase debería tener un único objetivo. También, se le puede conocer como la alta cohesión.

✨ Algo que nos ayuda este principio es a tener código más reutilizable.

Para complementar, es bastante interactivo y
fácil de entender https://youtu.be/_8ecJbcIJKM

Sería algo así.

//la clase Numbers tiene la responsabilidad de establecer los parametros en las demás clases.
class Numbers {
    constructor(num1, num2) {
        this.num1 = num1
        this.num2 = num2
    }
}

//La clase Sum tiene la responsabilidad de retornar la suma de 2 números.
class Sum extends Numbers {
    constructor(num1, num2) {
        super(num1, num2)
    }

    getSum() {
        return console.log(this.num1 + this.num2);
    }
}

const sum = new Sum(2, 4);
sum.getSum();

//La clase Multiplication tiene la responsabilidad de retornar el producto de 2 números.
class Multiplication extends Numbers {
    constructor(num1, num2) {
        super(num1, num2)
    }
    getMultiplication() {
        return console.log(this.num1 * this.num2);
    }
}

const multiplication = new Multiplication(4, 3);
multiplication.getMultiplication();

¡Que importante es aprender SOLID!

https://es.wikipedia.org/wiki/SOLID

Documento de referenia acerca de los princios de SOLID.
(2021). Retrieved 26 November 2021, from https://jbravomontero.files.wordpress.com/2012/12/solid-y-grasp-buenas-practicas-hacia-el-exito-en-el-desarrollo-de-software.pdf

che acá el ejemplo no queda claro… porque tipo, si clase usuario no tiene muchas responsabilidad, no veo razón de migrar esos métodos a clases, a menos que ya haya un comportamiento común entre varias clases que requieran de validación o relacionarse con la db

En este enlace que les comparto pueden encontrar una serie de recomendaciones para detectar cuándo podemos estar rompiendo el principio de responsabilidad única:
SRP

📌📋 Los 5 principios SOLID para el diseño de aplicaciones de software son:

• S – Single Responsibility Principle (SRP) o Principio de responsabilidad unica
• O – Open/Closed Principle (OCP) o Principio de abierto/cerrado
• L – Liskov Substitution Principle (LSP) o Principio de Sustitución de Liskov
• I – Interface Segregation Principle (ISP) o Principio de Segregación de Interface
• D – Dependency Inversion Principle (DIP) o Principio de Inversión de Dependencias

• las clases con una única responsabilidad tienen la posibilidad de volver a usar de una manera mas simple.

• procura no hacer las clases orquestas, esas clases que hacen muchas cosas y que seguramente tendrá problemas

SOLID significa:

S: Single Reponsibility Principle
O: Open/Closed Principle
L: Liskov Substitution Principle
I: Interface Segregation Principle
D: Dependency Inversion Principle

Nota Clase: Principio SOLID. Cinco principios básicos de la programación orientada a objetos, su objetivo es crear SW mantenible en el tiempo. Es posibe cuando tenemos terminado el SW podemos analizarlo con los principios de solid.
El principio de responsabilidad única (Single Reponsibility Principle) nos dice que una clase debe de tener solo una razón para cambiar, una alta cohesión, la ventaje es que podemos detectar los probles que encontremos, al tener clases que solo hacen una sola cosa la podemos reutilizar en otros proyectos.

Quizá para este curso ya no se pueda hacer, pero para futuros cursos sería mejor dejar la propuesta del reto en un video y en el siguiente mostrar una posible solución, así no se da por sentado que todas las respuestas de los estudiantes están correctas, ya que no hay feedback para ninguna de las soluciones realizadas por los estudiantes para el reto anterior

SRP: Un módulo debería tener una, y solo una, razón para cambiar

Principios SOLID

Los principios SOLID nos indican como ordenar nuestras funciones y nuestra estructura de datos en clases, y como deben interconectarse esas clases.

La meta de los principios es la creación de estructura de software de nivel medio que:

• Toleren el cambio

• Sean fáciles de comprender

• Sean las bases de componentes que pueden utilizarse en muchos sistemas de software.

El término “nivel medio” se refiere al hecho de que estos principios los aplican programadores que trabajan a nivel del módulo. Se aplican justo por encima del nivel del código y ayudan a definir los tipos de estructura de software que se utilizan en módulos y componentes.

1. SRP: El principio de responsabilidad única o SRP (Single Responsability Principle).
   La mejor estructura para un sistema de software se ver muy influenciada por la estructura social de la organización que lo utiliza, de modo que cada modulo de software tiene una, y sola una, razón para cambiar.
2. OCP: El principio de abierto-cerrado u OCP (Open-Closed Principle).
   La clave esta en para que los sistemas de software sean fáciles de cambiar, deben diseñarse de forma que permita que el comportamiento de dichos sistemas pueda cambiarse añadiendo código, en lugar de cambiar el código existente.
3. LSP: El principio de sustitución de Liskov o LSP (Liskov Substitution Principle).
   Este principio afirma que, para crear sistemas de software a partir de partes intercambiables, esas partes deben adherirse a un contrato que les permitan ser sustituida por otras.
4. IPS: Principio de segregación de la interfaz o SIP (Interface Segregation Principle).
   Este principio aconseja a los diseñadores de software que eviten depender de cosas que no utilizan.
5. DIP: El principio de inversión de dependencias o DIP (Dependency Inversión Principle).
   El código que implementa políticas de alto nivel no debería depender de código que implementa detalles de bajo nivel. Al contrario, los detalles deberían depender de las políticas.

Single Responsibility Principle (SRP)

Una clase debería tener un único objetivo. Una sola responsabilidad.

Principios SOLID

Cinco principios basicos de la programacion orientada a objetos

Ayudan a crear software mantenible en el tiempo.

1. Single Responsibility Principle: Que cada clase tenga una unica responsabilidad.

Supongo debe haber alguna flexibilidad de este principio. por que en ML es muy común que las librerías generen una clase para cada modelo e internamente tienen varios métodos como el de fit y predict.

En caso de validaciones una clase especifica es recomendable crear una clase abstracta ? saludos

Single Responsibility principle / Principio de responsabilidad única

Una clase debe tener sólo una razón para cambiar.

La ventaja de aplicar este principio, es fácil detectar los problemas que ocurren en la aplicación, pues cómo cada clase tiene solo un objetivo, es fácil encontrar donde esta el problema.

Al tener clases que solo hacen una sola cosa, se vuelven mucho más reutilizables.

Single Reponsibility Principle

Excelenete, no recuerdo haber escuchado de estos principios SOLID. Muy importante

Principios SOLID: Single Responsibility Principle

Una clase debe de tener solo una razon para cambiar y tener facilidad para encontrar problemas

Aplica para todo. Entre más sencillo sea el código más fácil será de reutilizar.

Me gusta como se estructuran las cosas

Ok yo creía que agrupar tanto como se pueda en la misma clase eran buenas prácticas y ya vi que no 😅

Tengo una duda. Capturé el ejemplo incorrecto y el correcto para mis apuntes, y el código es el mismo, una misma clase User.
Me equivoco o el código correcto debería tener 3 clases como lo sugiere el profesor?.

1. Principios SOLID - Single Responsibility Principle

S: principio de responsabilidad unica
O: Principio de abierto o cerrado
L: Principio de sustitucion Liskov
I: principio de segregacion de interface
D: Principio de inversion de dependencias

S - Una clase debe tener un unico objetivo, o alta cohecion, todo claro y un solo funcionamiento - Ayuda a detectar fallos, ya que se sabe quien fallo

Super importante la idea de tener una función con un único objetivo!
Si quieres profundizar acerca de los principios SOLID, te dejo un artículo y un vídeo que hablan acerca de los demás principios 😉

Yo pensaba que tener una clase con distintos métodos era efectivo, pero veo que es buena practica por cada clase que tenga una sola responsabilidad, eso me lo anoto. gracias

PRINCIPIO DE RESPONSABILIDAD UNICA
- Una clase solo debe ser responsable de una cosa.
- Hay un lugar para todo y todo está en su lugar.
- Encuentra una razón para cambiar y saca todo lo demás de la clase
- Nombres muy precisos para muchas clases pequeñas> nombres genéricos para clases grandes.

Interesante, desconocía este principio.

Comparto un video para reforzar el tema 😃
https://www.youtube.com/watch?v=2X50sKeBAcQ

SOLID son cinco principios básicos de la programación orientada a objetos que ayudan a crear software mantenible en el tiempo.

****Solid ****es un acrónimo inventado por Robert C.Martin para establecer los cinco principios básicos de la programación orientada a objetos y diseño. Este acrónimo tiene bastante relación con los patrones de diseño, en especial, con la alta cohesión y el bajo acoplamiento.

El objetivo de tener un buen diseño de programación es abarcar la fase de mantenimiento de una manera más legible y sencilla así como conseguir crear nuevas funcionalidades sin tener que modificar en gran medida código antiguo. Los costes de mantenimiento pueden abarcar el 80% de un proyecto de software por lo que hay que valorar un buen diseño.

“S-Responsabilidad simple (Single responsibility)
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 pensamos ““Ya que estamos aquí, para que voy a crear una clase para realizar esto. Directamente lo pongo aquí””.”

“O-Abierto/Cerrado (Open/Closed)
Principio atribuido a Bertrand Meyer que habla de crear clases extensibles sin necesidad de entrar al código fuente a modificarlo. Es decir, el diseño debe ser abierto para poderse extender pero cerrado para poderse modificar. Aunque dicho parece fácil, lo complicado es predecir por donde se debe extender y que no tengamos que modificarlo. Para conseguir este principio hay que tener muy claro como va a funcionar la aplicación, por donde se puede extender y como van a interactuar las clases.”

“L-Sustitucion Liskov (Liskov substitution)
Este principio fue creado por Barbara Liskov y habla de 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.”

“I-Segregacion del interface (Interface segregation)
Este principio fue formulado por Robert C. Martin y trata de algo parecido al primer principio. 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 muchos interfaces que definan pocos métodos que tener un interface con muchos métodos.”

“D-Inversión de dependencias (Dependency inversion)
También fue definido por Robert C. Martin. El objetivo de este principio conseguir desacoplar las clases. 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.”

fuente: https://www.genbeta.com/desarrollo/solid-cinco-principios-basicos-de-diseno-de-clases

Todo clarísimo. Gracias

Que pasa cuando el proyecto es bastante grande, no será difícil moverse por tantas clases?

El principio de Responsabilidad simple, se debe realizar en las clases para lograr la reutilización de estas instancias mas fácilmente a lo largo del desarrollo del proyecto.

S > Identificar al culpable mucho mas facil

https://architectcoders.com/wp-content/uploads/2019/08/principios-solid-devexperto.pdf

Conclusión:
“El Principio de Responsabilidad Única es una herramienta indispensable para
proteger nuestro código frente a cambios, ya que implica que sólo debería haber
un motivo por el que modificar una clase.
En la práctica, muchas veces nos encontraremos con que estos límites tendrán más
que ver con lo que realmente necesitemos que con complicadas técnicas de disección.
Tu código te irá dando pistas según el software evolucione”

S: Single Reponsibility Principle - Principio de responsabilidad única o Alta cohesión:
Una clase debería tener un unico objetivo, muy claro y conciso. Aplicar este principio es ventajoso pues facilita detectar los problemas que puedan surgir, por otra parte, tener clases con objetivos muy especificos las convierte mucho más reutilizables. La idea principal es evitar una clase que haga muchas cosas.

la clase debería estar destinada a una única responsabilidad y no mezclar la de otros o las que no le incumben a su dominio

Me parece que aquí están más claro los principios SOLID. https://www.youtube.com/watch?v=2X50sKeBAcQ

Los principios SOLID son buenas prácticas que pueden ayudar a escribir un mejor código: más limpio, mantenible y escalable.

Single Responsibility Principle