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 鈥渁bierto-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:

Los aportes, preguntas y respuestas son vitales para aprender en comunidad. Reg铆strate o inicia sesi贸n para participar.

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

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 鈥渁bierto-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 鈥渁bierto-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

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 ^^