Newsletter para devsEntra

Manual de buenas prácticas: S de S.O.L.I.D. Responsabilidad única

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 originalmente por: Juan José Ramos

Imagen de Daniel Primo

Daniel Primo

CEO en pantuflas de Web Reactiva. Programador y formador en tecnologías que cambian el mundo y a las personas. @delineas en twitter y canal @webreactiva en telegram

12 recursos para developers cada domingo en tu bandeja de entrada

Además de una skill práctica bien explicada, trucos para mejorar tu futuro profesional y una pizquita de humor útil para el resto de la semana. Gratis.