A煤n no tienes acceso a esta clase

Crea una cuenta y contin煤a viendo este curso

Principios SOLID: Single Responsibility Principle

11/26
Recursos

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

SOLID significa:

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

La S se trata de una clase que debe tener s贸lo una raz贸n para cambiar.

Aportes 53

Preguntas 7

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesi贸n.

El principio de responsabilidad 煤nica (tambi茅n conocido como 鈥渓a 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 鈥渉ombre orquesta鈥.

Este principio no solo se aplica a las clases, igual se aplica a las funciones, 驴Alguna vez has escuchado decir 鈥渦na 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!

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.

鈥淪-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 鈥溾淵a que estamos aqu铆, para que voy a crear una clase para realizar esto. Directamente lo pongo aqu铆鈥濃.鈥

鈥淥-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.鈥

鈥淟-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.鈥

鈥淚-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.鈥

鈥淒-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:
鈥淓l 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.

Si tienen dudas de SOLID, este art铆culo tiene otros ejemplos complementarios a los que aqu铆 se explican. https://www.google.com/amp/s/www.digitalocean.com/community/conceptual_articles/s-o-l-i-d-the-first-five-principles-of-object-oriented-design.amp

Single Responsibility Principle