Cursos Empresas Blog Live Conf Eventos Precios

0:003:25

Recursos

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.

Principios SOLID: Single Responsibility Principle

Curso de Patrones de Diseño y Buenas Prácticas en PHP

Clase 11 / 26

Ver clases

Principios SOLID: Single Responsibility Principle

Curso de Patrones de Diseño y Buenas Prácticas en PHP

Clase 11 de 26

Clase 11 / 26

Principios SOLID: Single Responsibility Principle

Curso de Patrones de Diseño y Buenas Prácticas en PHP

Clase 11 / 26

Ver clases

Comentarios

Bernardo Ayala Montezuma#855566

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

Carlos Eduardo Gomez García#1822192

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é

Juan Pena Verdú#665721

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.

Jhon Alexander Romero Gonzaga#930275

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#1850842

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.

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

Comentarios

Bernardo Ayala Montezuma#855566

Carlos Eduardo Gomez García#1822192

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é

Juan Pena Verdú#665721

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.

Jhon Alexander Romero Gonzaga#930275

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#1850842

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.

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

Comentarios (66)66 comentarios

Bernardo Ayala Montezuma

Hace 7 años

Bernardo Aguayo Ortega

Hace 6 años

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

Juan Pablo Celiz

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

Damian Castellini

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.

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ú

así de simple!!

Jhon Alexander Romero Gonzaga

María Sierra

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

Darwin Salinas

Hace 5 años

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!

Sería algo así.

Luis fernando Valderrama Gastiaburu

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

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

Jorge Paiva

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

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

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

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.

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

¿Qué nos enseña el Single Responsibility Principle

Edwin Jorge Arroyo

¡Hola!

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

Anthony Smith Quispe De la cruz

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

Hace 4 años

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

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

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

Rubén Maier Enzler

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

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

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

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

Nada, el link no sirve

Luz Sthephany Granados Castro

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

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

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

Recursos

Resumen

Principios SOLID: Single Responsibility Principle

Principios SOLID: Single Responsibility Principle

Principios SOLID: Single Responsibility Principle

Progreso del curso

Comprender los objetivos y pre-requisitos del curso

Aprender a escribir código legible

Aprender a escribir código mantenible

Escribir código libre de vicios

Conocer los principios SOLID

Conocer los conceptos de Patrones de diseño y su aplicación

Comprender las nociones de testing automatizado

Incorporar habilidades para el trabajo en equipo

Reforzar lo aprendido

Principios SOLID: Single Responsibility Principle

Principios SOLID: Single Responsibility Principle

Recursos

Resumen

Comentarios

Principios SOLID: Single Responsibility Principle

Single Responsibility Principle

Recursos

Resumen

Comentarios

Principios SOLID: Single Responsibility Principle

Single Responsibility Principle