Principios SOLID: Single Responsibility Principle

Clase 11 de 26 • Curso de Patrones de Diseño y Buenas Prácticas en PHP

Resumen

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.

Bernardo Ayala Montezuma

student•

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".

Bernardo Aguayo Ortega

student•

Ojala alguien me hubiera enseñado esto al principio de mi carrera

Juan Pablo Celiz

student•

Excelente aporte! Un pequeño detalle, es "alta cohesión" y no "lata". Casi lo mando así en mi apunte 😁

Carlos Eduardo Gomez García

teacher•

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é

Damian Castellini

student•

Exacto, de hecho ++CREO ++ que esta mal explicado. Las clases adentro pueden hacer varias cosas, pero lo importante es que esas varias cosas sean totalmente individuales unas de otras y sean hechas en distintas funciones donde cada una haga algo concreto y conciso.

Pasado en limpio, que los metodos de las clases hagan solo una cosa, no importa la cantidad de metodos si el contexto es correcto con la clase.

Carlos Eduardo Gomez García

teacher•

De hecho si está bien explicado, como tú dices "si el contexto es correcto con la clase", a eso se refería el profesor jaja, claro que una clase puede tener muchos métodos, pero siempre es bueno mirar si esas acciones internas se pueden delegar a una clase aún más especifica, como en la clase Carro, dentro puedes poner métodos para controlar las llantas, pero es una mejor idea delegar esos métodos a una clase Llanta más específica :D

Juan Pena Verdú

student•

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.

Bernardo Aguayo Ortega

student•

así de simple!!

Jhon Alexander Romero Gonzaga

student•

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)

María Sierra

student•

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.

Darwin Salinas

student•

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

Usuario anónimo

user•

¡Que importante es aprender SOLID!

Usuario anónimo

user•

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();

Luis Val

student•

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

Juan Pena Verdú

student•

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

Jorge Luis Paiva Huamán

student•

Este código es de algún framework como Zend, Laravel?

Carlos Eduardo Gomez García

teacher•

No, son solo ejemplos que escribió el profesor para explicar mejor todo esto, aunque de hecho, esos frameworks siguen estas prácticas de buena escritura de código :D

Enrique Gamboa

student•

Según el ejemplo que puso el profesor, ¿En qué clases deberían ir el método de validación y consulta? Para mí hacen perfecto sentido que vayan en esta misma clase pues van orientadas hacia validar al usuario y traer información del usuario desde la base de datos. ¿O quizá hay una mejor manera de ordenar estos métodos?

Carlos Herrera

student•

e me ocurre que luego de que el usuario sea validado podría haber una clase con esas acciones.

No se que tan correcto sea mi idea.

Enrique Gamboa

student•

Me he vuelto a ver la clase y me hace perfecto sentido lo que comenta el profesor. Al dividir todo en distintas clases tienes un código mucho más organizado, entendible y mantenible.

Julio Enrique Chávez García

student•

¿Qué nos enseña el Single Responsibility Principle

Edwin Jorge Arroyo

student•

¡Hola!

Echale un vistazo a este artículo :), aquí hablarán a mayor profundidad sobre Single Responsibility Principle ;).

Anthony Smith Quispe De la cruz

student•

En los aportes de la clase nuestros compañer@s muestran sus explicaciones, siéntete libre de comentarlas y responderles. Yo te diría que los principios SOLID te explican maneras de tener un producto software más mantenible.

Eduardo Reyes

student•

🍃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

Que explican:

La S se trata de una clase que debe tener sólo una razón para cambiar.
O: Princpio Abierto/Cerrado. Las entidades de software (clases, módulos, funciones, etc.) deben estar abiertas para extensión pero cerradas para modificación.
L: Princpio de sustitución de Liskov. Los objetos de una clase base deben poder ser reemplazados por objetos de clases derivadas sin afectar la integridad del programa.
I: Princpio de segregación de la interfaz. Las interfaces de software deben ser específicas para cada cliente y no deben incluir métodos que el cliente no necesite.
D: Princpio de inversión de dependencia. Los módulos de software de alto nivel no deben depender de módulos de bajo nivel. En su lugar, ambos deben depender de abstracciones.

Ronnie Bejerano

student•

cambiando la orquesta de mi código jajaja, de verdad me abrió los ojos el principio de responsabilidad única.

Rubén Maier Enzler

student•

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

Fernando Arriola Colunga

student•

Hola.

Por lo que entendí el objetivo de aplicar los principios SOLID es hacer el programa más robusto en el tiempo. Con esto me refiero a que es muy probable que separar cada una de las funciones mencionadas sea la mejor opción para que el día de mañana se nos facilite leer el código.

Con un código robusto a través del tiempo podremos no solo reutilizar dicho programa sino incluso escalarlo en nuevos proyectos con mayor facilidad.

Saludos!!

William Rodriguez

student•

una clases es una representacion abstracta de algo de la vida real.

1.User su responsabilidad es contener la estructura del usuario . 2. validadorUser tiene la responsabilidad de realizar diferentes tipos de validaciones a la User 3. UserRepository tiene la responsabilidad de realizar operaciones en bd

si bien tienen pocas responsabilidades no se trata de la cantidad si no de agrupar las responsabilidades diferentes en clases diferentes.

Esto es muy comun en las sistemas diseñados en capas algo casi nativo en java o c# capa de servicios (Rest, SOAP, HTML-js-css) , capa de logica(Domain) , entidades(tablasDB o coleccionesDB), repositorio(operaciones DB) todas responsabilidades diferentes

Entonces tienes una entidad USER tendriamos : UserRest, UserDomain, UserRepository, UserEntity

esta UserRest pero ahora nos piden de user hacer un servicio SOAP entonces UserSoap va a utilizar UserDomain que tiene toda la logica y ya asi mismo un UserWeb es mas mantenible ,reutilizable.

Jherom Chacon

student•

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

José Darío Bedoya Ortiz

student•

Nada, el link no sirve

Luz Sthephany Granados Castro

student•

📌📋 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

Abigail Perez

student•

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

Juan Pena Verdú

student•

SOLID significa:

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