No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Curso Avanzado de PHP

Curso Avanzado de PHP

Héctor Benitez

Héctor Benitez

SOLID

12/35
Recursos

SOLID nos habla de 5 principios básicos de la programación orientada a objetos. Estos 5 principios ayudan a tener un código más claro y más limpio aunque no son fáciles de implementar en un principio. La recomendación es que sigas intentando hacerlo, que sigas leyendo, entrenando y preparándote y todo va a ir saliendo de manera natural.

SOLID:

  • Single responsibility principle o principio de responsabilidad única. Quiere decir que cuando crees una clase, ésta sólo debe tener un propósito que debe ser sencillo; el no hacerlo hace que nuestro código se pueda ver afectado ya que una sola cosa controla muchas otras.
  • Open-closed principle o principio “abierto-cerrado”. Trata de explicarnos que deberíamos programar nuestras clases pensando que sean abiertas a la extensión pero cerradas a la modificación. Debemos tratar que nuestras clases estén listas para ser heredadas o extendidas pero no deba ser necesario modificar el código interno.
  • Liskov substitution principle o principio de sustitución de Liskov. Nos dice que cuando tenemos una clase padre y creamos clases hijas, en las partes en las que usemos nuestra clase padre, deberíamos ser capaces de usar nuestras clases hijas. Las clases hijas deben poder funcionar con lo que funcionaba la clase padre.
  • Interface segregation principle o segregación de interfaces. Dice que no debemos implementar o tener interfaces que incluyan métodos o cosas que la clase no necesita.
  • Dependency inversion principle o inversión de dependencias. Trata de desacoplar nuestro código; en lugar de crear clases internamente, vamos a inyectarlas o agregarlas. La inyección de dependencias se usa mucho.

Aportes 34

Preguntas 1

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

o inicia sesión.

SOLID es un acrónimo de los cinco principios del diseño orientado a objetos (OOD Object Oriented Design) creados por Uncle Bob, quien también es coautor de los principios del desarrollo web agile.

Los cinco principios son:
S. Single responsibility principle
O. Open/Closed principle
L. Liskov substitution principle
I. Interface segregation principle
D. Dependency Inversion Principle

Estos principios combinados facilitan al desarrollador crear proyectos fáciles de mantener y expandir.

  1. Single responsibility principle

Una clase sólo debe tener un motivo para cambiar, lo que significa que sólo debe tener una tarea. Tenemos varias figuras de las que después queremos calcular su área total:

Class Circle 
{
    public $radius;

    public function __construct($radius) 
    {
        $this->radius = $radius;
    }
}

Class Square 
{
    public $length;

    public function __construct($length) 
    {
        $this->length = $length;
    }
}

Primero creamos las clases de las figuras y dejamos que los constructores se encarguen de recibir las medidas necesarias.

Ahora creamos la clase AreaCalculator, que recibe un array con los objetos de cada una de las figuras para ser sumadas:

class AreaCalculator
{
    protected $shapes;

    public function __construct($shapes = array())
    {
        $this->shapes = $shapes;
    }

    public function sum()
    {
        // Aquí va la lógica para sumar todas las áreas
    }

    public function output()
    {
        return implode('', array(
            "<h1>",
                "Suma de todas las áreas: ",
                $this->sum(),
            "</h1>"
        ));
    }
}

Para utilizar la clase AreaCalculator simplemente instanciamos la clase y le pasamos un array con las figuras, mostrando el output al final:

$shapes = array (
    new Circle(3),
    new Square(4)
);

$areas = new AreaCalculator($shapes);

echo $areas->output();```

El problema del método output es que la clase AreaCalculator además de calcular las áreas maneja la lógica de la salida de los datos. El problema surge cuando queremos mostrar los datos en otros formatos como json, por ejemplo.

El principio Single responsibility determinaría en este caso que AreaCalculator sólo calculase el área, y que la funcionalidad de la salida de los datos de produjera en otra entidad. Para ello podemos crear la clase SumCalculatorOutputter, que determinará como mostraremos los datos de las figuras. Con esta clase el código quedaría así:

4-Segregación de Interfaces: (Interface Segregation) Una interfaz no debería tener métodos o propiedades que no utilice.

Este vídeo es muy útil para entender lo que se ve en este episodio del curso y en el próximo episodio.

POO: El desacoplamiento entre clases y el uso de interfaces, vídeo encontrado por: @flavioaandres

Genial, me parece que se explicaron muy bien estos principios de manera muy resumida.

Si quieren profundizar más en estos principios les recomiendo el curos de buenas prácticas de escritura de código, ahí se hablan muy a fondo de cada uno de estos y hasta con ejemplos ^^

SOLID nos habla de 5 principios básicos de la programación orientada a objetos. Estos 5 principios ayudan a tener un código más claro y más limpio aunque no son fáciles de implementar en un principio. La recomendación es que sigas intentando hacerlo, que sigas leyendo, entrenando y preparándote y todo va a ir saliendo de manera natural.

Single responsibility principle o principio de responsabilidad única. Quiere decir que cuando crees una clase, ésta sólo debe tener un propósito que debe ser sencillo; el no hacerlo hace que nuestro código se pueda ver afectado ya que una sola cosa controla muchas otras.

Open-closed principle o principio “abierto-cerrado”. Trata de explicarnos que deberíamos programar nuestras clases pensando que sean abiertas a la extensión pero cerradas a la modificación. Debemos tratar que nuestras clases estén listas para ser heredadas o extendidas pero no deba ser necesario modificar el código interno.

Liskov substitution principle o principio de sustitución de Liskov. Nos dice que cuando tenemos una clase padre y creamos clases hijas, en las partes en las que usemos nuestra clase padre, deberíamos ser capaces de usar nuestras clases hijas. Las clases hijas deben poder funcionar con lo que funcionaba la clase padre.

Interface segregation principle o segregación de interfaces. Dice que no debemos implementar o tener interfaces que incluyan métodos o cosas que la clase no necesita.

Dependency inversion principle o inversión de dependencias. Trata de desacoplar nuestro código; en lugar de crear clases internamente, vamos a inyectarlas o agregarlas. La inyección de dependencias se usa mucho.

3- Principio de Sustitución de Liskov:(Liskov Substitution) Cuando tenemos una clase padre y creamos clases hijas. Al menos las clases hijas deberían funcionar con lo que funcionaba la clase Padre.

5-Principio de Inversión de dependencias:(Dependency inversion) Trata de desacoplar nuestro código utilizando la inyección de dependencias.

2-Principio Abierto-Cerrado:(Open-Close principle) Deberíamos crear clases abiertas a la extensión y cerradas a la modificación. Pensar en una clase padre para que pueda ser heredada por otra hija y así extenderse.Así se Evita tener que modificar la clase padre.

El principio de responsabilidad única está relacionado o es, lo que se conoce como cohesión y en relación a esto, el acoplamiento?

increíble clase!! maestro

Vine a entender SOLID. Gracias!

CITA del libro de Arquitectura limpia de Robert C. Martin:
OCP (Open-Closed Principle)
Bertrand Meyer hizo famoso este principio en la década de 1980, la clave está en que para que los sistemas de software sean fáciles de cambiar, deben diseñarse de forma que se permita que el comportamiento de dichos sistemas pueda cambiarse añadiendo código, en lugar de cambiar el código existente

SOLID -> Para mi es es fundamental para el desarrollo escalable y de al nivel

Bueno, desconozco si este es el lugar adecuado pero me gustaria felicitar a Hector por dar una explicacion tan clara y concisa de un tema tan importante como los principios SOLID. Estoy realmente impresionado. Gracias!

Me gustó este artículo sobre SOLID. Aunque las definiciones que da a cada principio son simples, tiene muchas referencias a otros artículos y bibliografía.

Como consigo guardar un campo calculado en un migration

Single responsibility principle o principio de responsabilidad única.

CITA del libro de Arquitectura limpia de Robert C. Martin:
ISP: (Interface Segregation Principle)
Este principio aconseja a los diseñadores de software que eviten depender de cosas que no utilizan

genial

CITA del libro de Arquitectura limpia de Robert C. Martin:
LSP (Liskov Substitution Principle)
La famosa definición de los subtipos de Barbara Liskov, de 1988. De forma breve este principio afirma que , para crear sistemas de software a partir de partes intercambiables, esas partes deben adherirse a un contrato que les permiten ser sustituidas por otras

SOLID nos habla de 5 principios básicos de la programación orientada a objetos. Estos 5 principios ayudan a tener un código más claro y más limpio aunque no son fáciles de implementar en un principio. La recomendación es que sigas intentando hacerlo, que sigas leyendo, entrenando y preparándote y todo va a ir saliendo de manera natural

Single responsibility principle o principio de responsabilidad única. Quiere decir que cuando crees una clase, ésta sólo debe tener un propósito que debe ser sencillo; el no hacerlo hace que nuestro código se pueda ver afectado ya que una sola cosa controla muchas otras

Open-closed principle o principio “abierto-cerrado”. Trata de explicarnos que deberíamos programar nuestras clases pensando que sean abiertas a la extensión pero cerradas a la modificación. Debemos tratar que nuestras clases estén listas para ser heredadas o extendidas pero no deba ser necesario modificar el código interno

Liskov substitution principle o principio de sustitución de Liskov. Nos dice que cuando tenemos una clase padre y creamos clases hijas, en las partes en las que usemos nuestra clase padre, deberíamos ser capaces de usar nuestras clases hijas. Las clases hijas deben poder funcionar con lo que funcionaba la clase padre

Interface segregation principle o segregación de interfaces. Dice que no debemos implementar o tener interfaces que incluyan métodos o cosas que la clase no necesita

Dependency inversion principle o inversión de dependencias. Trata de desacoplar nuestro código; en lugar de crear clases internamente, vamos a inyectarlas o agregarlas. La inyección de dependencias se usa mucho

CITA del libro de Arquitectura limpia de Robert C. Martin:
SRP: (Single Responsibility Principle)
"Un corolario activo a la ley de Conway: la mejor estructura para un sistema de software se ve muy influenciada por la estructura social de la organización que lo utiliza, de modo que cada módulo de software tiene una, y sólo una, razón para cambiar.

CITA del libro de Arquitectura limpia de Robert C. Martin:
DIP (Dependency Inversion Principle)
El código que implementa las políticas de alto nivel no debería, depender del código que implementa detalles de bajo nivel. Al contrario, los detalles deberían depender de las políticas

esto esta buscando, excelente