Siguiendo con nuestro manual de buenas prácticas, hoy nos adentramos dentro de uno de los estándares más conocidos en el mundo de la programación.

En este caso, los principios S.O.L.I.D, están fuertemente ligados a la programación orientada a objetos y establecen cinco reglas que ayudarán a que nuestro código sea más legible y más mantenible.

Sólo como pequeña introducción, decir que S.O.L.I.D. significa "sólido" en inglés, pero aunque esta palabra dice ya mucho por si sola, se trata de una regla mnemotécnica que incluye cinco principios (os dejo enlaces a los otros artículos de la serie):

Si queréis aprender un poquito más sobre todos estos principios, os aconsejo que os paséis por el episodio #93 de Web Reactiva donde se habla de los principios S.O.L.I.D. para novatos.

Bueno, ¿a qué esperamos para meternos de lleno en la letra: S?

Principio de responsabilidad única

Como su propio nombre indica: responsabilidad única, este principio viene a decir que:

Un objeto o clase sólo debe realizar una acción encomendada

Manua-buenas-practicas-S.O.L.I.D-S

Si llevas un tiempo en esto de la programación, seguramente te habrás dado cuenta de que tendemos a crear clases que tienen responsabilidades muy diversas:

  • Declaración de propiedades del objeto.
  • Seteo de alguna que otra propiedad.
  • Grabar datos en una base de datos o archivo (persistencia).
  • Consultar datos del objeto.

Esto, aunque bien puede parecer que encapsula toda la funcionalidad en una sola clase, deriva en que las mismas tengan una extensión kilométrica, algo que no está nada mal cuando la aplicación es pequeña pero que se vuelve una auténtica locura cuando la clase crece.

Pues bien, el principio de responsabilidad única viene a decirnos que si podemos disgregar aún más el objeto y separar las distintas funcionalidades, esto hará que las funcionalidades sean aún más fáciles de mantener en el tiempo.

En este ejemplo vamos a trabajar con un objeto factura, y aplicaremos la funcionalidad de declaración de alguna de sus propiedades, impresión de la misma y guardar toda su información en la base de datos.

No entraré en el código que realizar cada una de las acciones, ya que nos desviaría del propósito del artículo.

Veamos el código que no seguiría el principio.

class Invoice{
        
    private $number;
    private $date;
    private $client;
    
    public function setProperties(){
    
        //modificación de propiedades
    
    }
    
    public function print(){
    
        //impresión por pantalla de la factura
    
    }
    
    public function SaveToDatabase(){
    
        //persistencia de datos
    
    }

}

Como podéis ver, todas las funcionalidades están declaradas dentro de la frase.

Lo que se nos pide ahora es separar las tres funcionalidades que dan lugar a tres clases distintas.

Este es el código refactorizado:

class Invoice{
        
    private $number;
    private $date;
    private $client;
    
    public function setProperties(){
    
        //modificación de propiedades
    
    }
    
}

class PrintInvoice{
    
    public function toScreen($invoiceNumber){
    
        //impresión por pantalla de la factura
    
    }
    
}

class SaveInvoiceToDB{
    
    public function SaveToDatabase($invoiceData){
    
        //persistencia de datos
    
    }    
    
}

Ahora seguro que os queda mucho más claro.

Podemos ver claramente cada una de las funcionalidades ya que el mismo nombre de la clase ya nos está diciendo la acción que esta realiza.

Además, a la hora de modificar este código en un futuro, será mucho más fácil discernir donde tenemos que realizar la modificación o ampliación.

¿Sabríais decirme dentro de qué clase iría la definición del método que imprime la factura en PDF?

Si quieres seguir profundizando en los conceptos de SOLID, escucha este podcast para novatos.

Espero haber aclarado un poquito más el termino de responsabilidad única y como ya sabéis:

¡Nos vemos en el siguiente fragmento de conocimiento, equipo!


Escrito por Juan José Ramos

Soy programador web, artesano del código y estudiante incansable. Aunque mi carrera siempre ha ido ligada al backend , últimamente me estoy dejando llevar por las lindezas del front.
No hay nada que me guste más que indentar y pulsar [ENTER] ;).
comments powered by Disqus