Tribalyte Technologies Tribalyte Technologies
  • Inicio
  • Misión y visión
  • Nuestros expertos
  • Nuestras soluciones
  • Casos de éxito
  • Blog
  • Contáctanos
  • Únete al equipo
Tribalyte Technologies Tribalyte Technologies
  • Inicio
  • Misión y visión
  • Nuestros expertos
  • Nuestras soluciones
  • Casos de éxito
  • Blog
  • Contáctanos
  • Únete al equipo
Oct 27
Principios SOLID - Single responsability

¿Cuáles son los principios S.O.L.I.D. ? «Single Responsability»

  • octubre 27, 2020
  • Monica Rebordinos
  • 6 Comments
  • Consejos tecnológicos, Desarrollo de aplicaciones, Desarrollo de software, Tecnologías

S.O.L.I.D. es el acrónimo de los cinco principios básicos de la programación orientada a objetos. Los principios S.O.L.I.D. fueron definidos por Robert C. Martin en su publicación “Design Principles and Design Patterns”.

Lo veremos todos en detalle a continuaciónpero antes es fundamental una breve introducción.

Ingeniería del software principiosSOLID

Aunque no lo parezca, los primeros ordenadores digitales llevan con nosotros menos de un siglo, y de hecho el término como tal de «Ingeniería del Software» aparece por primera vez a mediados del siglo XX. En contraste, términos como «arquitectura» datan desde el siglo I a.C., por lo que podemos decir que la Ingeniería de Software sigue siendo un campo muy joven. Seguimos aprendiendo día a día de los errores propios (y de los demás), tratando de evolucionar y de evitar repetirlos para ser más productivos y eficientes. Así poco a poco vamos definiendo los principios y buenas prácticas para el desarrollo de software.

Dentro de esos principios, unos de los más conocidos fueron justamente los cinco princicpios S.O.L.I.D. definidos por Robert C. Martin. El conocer y aplicar estos principios ofrecen una serie de ventajas al desarrollador a la hora de programar, independientemente del lenguaje utilizado. El código resultante estará menos acoplado por lo que será más fácil de extender, de mantener, más legible, reutilizable y más sencillo realizar test unitarios. En conclusión tendremos un mejor diseño en la arquitectura de la aplicación y un código de mayor calidad.

Index

  • 1 ¿Qué significa el acrónimo S.O.L.I.D.?
    • 1.1 Single responsibility principle – Principio de responsabilidad única
    • 1.2 Open-closed principle – Principio de abierto-cerrado
    • 1.3 Liskov substitution principle – Principio de sustitución de Liskov
    • 1.4 Interface segregation principle – Principio de segregación de interfaces
    • 1.5 Dependency inversion principle – Principio de inversión de dependencias
  • 2 Single responsibility principle – Principio de responsabilidad única
  • 3 Un ejemplo real en Java de como aplicar el principio de responsabilidad única

¿Qué significa el acrónimo S.O.L.I.D.?

Single responsibility principle – Principio de responsabilidad única

Open-closed principle – Principio de abierto-cerrado

Liskov substitution principle – Principio de sustitución de Liskov

Interface segregation principle – Principio de segregación de interfaces

Dependency inversion principle – Principio de inversión de dependencias

Single responsibility principle – Principio de responsabilidad única

Hoy nos centraremos en el primer principio SOLID, el principio de responsabilidad única.

Este principio establece que cada clase debe tener una única responsabilidad dentro de nuestro software, y esta responsabilidad debe estar definida y ser concreta. Todos los métodos deben estar alineados con la finalidad de la clase.

“Una clase debe tener solo una razón para cambiar” – Uncle Bob

Si nos encontramos con una clase que dispone de métodos que realiza tareas con distintas finalidades se debería refactorizar el código y crear clases nuevas que se corresponda con los objetivos del método.

Definir la responsabilidad única de una clase no es una tarea fácil, será necesario un análisis previo de las funcionalidades y cómo estructuramos la aplicación. Gracias a este principio nuestras clases tendrán un bajo acoplamiento y a la hora de realizar cambios menos clases se verán afectadas.
Algunos síntomas que nos pueden hacer sospechar (bad smells) que no se está cumpliendo este principio serían:

  • Una clase es demasiado larga, demasiadas líneas de código.
  • Cada vez que hay que introducir una modificación o una nueva funcionalidad, es necesario tocar en muchos sitios.
  • Hay demasiadas relaciones entre clases.
  • Mezcla funcionalidades de distintas capas de la arquitectura.

Un ejemplo real en Java de como aplicar el principio de responsabilidad única

Tenemos una aplicación cuya función es calcular la suma del área de dos polígonos y mostrar el resultado al usuario. En un principio podríamos tener clases para definir los objetos Square y Circle que extienden de la clase padre Polygon.

 

public class Square extends Polygon {

    int side;

    public Square(int side){
        this.side = side;
    }

    public int getSide(){
        return this.side;
    }

    public void setSide(int side){
        this.side = side;
    }

    public double getArea(){
        return Math.pow(side,2);
    }

}


public class Circle extends Polygon {

    int radius;

    public Circle(int radius){
        this.radius = radius;
    }

    public int getRadius(){
        return this.radius;
    }

    public void setRadius(int radius){
        this.radius = radius;
    }

    public double getArea(){
        return Math.PI * Math.pow(radius,2);
    }

}

También crearemos una clase que realice los cálculos que necesitamos.

public class CalculationService {

    public void sumAreas(Polygon poligon1, Polygon poligon2){
        System.out.print(poligon1.getArea() + poligon2.getArea());
    }

    public void diffAreas(Polygon poligon1, Polygon poligon2){
        System.out.print(poligon1.getArea() - poligon2.getArea());
    }
}

En la aplicación principal creamos los objetos y llamamos al método de sumar las áreas:

  Circle circle = new Circle(5);
  Square square = new Square(6);

  CalculationService calculationService = new CalculationService();
  calculationService.sumAreas(circle, square);

Podríamos pensar que está bien crear el método de mostrar el resultado por pantalla dentro de la misma clase que realiza los cálculos, pero estaremos violando el principio de responsabilidad única, ya que no deberíamos mezclar la capa de presentación con la lógica de negocio, y posiblemente en un futuro si queremos actualizar la forma en que se muestra al usuario el resultado o queremos realizar nuevos cálculos vamos a tener que modificar todos nuestros métodos de la clase CalculationService.
Aplicando el principio de responsabilidad única para refactorizar el código crearíamos una nueva clase PrintService en la que implementaremos las funciones encargadas de la presentación de nuestra aplicación:

public class PrintService {

    public void printResult(double result){
        System.out.print("-- Result = " + result);
    }

}

La clase CalculationService solo quedaría como responsable de realizar los cálculos:

public class CalculationService {

    public double sumAreas(Polygon poligon1, Polygon poligon2){
        return poligon1.getArea() + poligon2.getArea();
    }

    public double diffAreas(Polygon poligon1, Polygon poligon2){
        return poligon1.getArea() - poligon2.getArea();
    }

}

En la aplicación principal estaríamos utilizando los dos servicios, con la posibilidad de reutilizar el resultado para otros cálculos o de crear nuevos métodos en el PrintService para mostrar el resultado en distintos formatos.

   CalculationService calculationService = new CalculationService();
   PrintService printService = new PrintService();

   Circle circle = new Circle(5);
   Square square = new Square(6);

   double result = calculationService.sumAreas(circle, square);
   printService.printResult(result);

Esperamos que estos ejemplos os hayan ayudado a entender el primer principio de SOLID y ver su gran importancia en el proceso de desarrollo de software.

Esto ha sido todo con lo que respecta a la «S» de S.O.L.I.D. pero, si quieres saber más sobre el resto de principios, consulta nuestros artículos:

 

  • Single responsibility principle – Principio de responsabilidad única
  • Open-closed principle – Principio de abierto-cerrado
  • Liskov substitution principle – Principio de sustitución de Liskov
  • Interface segregation principle – Principio de segregación de interfaces
  • Dependency inversion principle – Principio de inversión de dependencias

 

Artículos Relacionados:

  • ¡Feliz Año Nuevo!¡Feliz Año Nuevo!
  • revisión códigoLa importancia de la revisión de código como parte de la política de calidad de la organización
  • image5Aplicación completa usando Angular Material
  • Programa o Compilador | ¿Qué fue primero? ¿Quién lo inventó? | Tribalyte Technologies¿Qué fue primero el programa o el compilador?
  • Tribalyte-links-google linkIntroducción a NgRx
  • Facebook
  • Twitter
  • LinkedIn
  • E-Mail

About The Author

Mónica es desarrolladora de software en Tribalyte, especializada en tecnologías móviles. Posee una amplia experiencia en el desarrollo de aplicaciones nativas Android (Kotlin / Java) e iOS (Swift / Objective-C). Amante de las nuevas tecnologías, las buenas prácticas de desarrollo, el testing y mantenerse siempre formada.

Related Posts

  • «Principio Solid Liskov» ¿Cuáles son los principios S.O.L.I.D.?septiembre 14, 2018
  • Principios S.O.L.I.D. – «Open-Closed»mayo 17, 2018

6 Comments

  1. Jaime
    octubre 29, 2020 at 11:11 pm · Responder

    Sencillo y directo. Buena publicación, Mónica.

  2. Carlos Ruiz
    febrero 8, 2019 at 8:13 am · Responder

    Excelente trabajo Monica, saludos desde Mexico

  3. Principios Solid Liskov substitution principle
    diciembre 23, 2018 at 8:12 pm · Responder

    […] Single responsability principle – Principio de responsabilidad única […]

  4. PRINCIPIOS S.O.L.I.D. - INTERFACE SEGREGATION - Tribalyte Technologies
    noviembre 8, 2018 at 6:11 pm · Responder

    […] Single responsability principle – Principio de responsabilidad única […]

  5. Principios S.O.L.I.D. - "Open-Closed" - Tribalyte Technologies
    mayo 18, 2018 at 12:12 pm · Responder

    […] con nuestro repaso de los principios SOLID, en anteriores entradas vimos el principio de responsabilidad única. Hoy nos centraremos en el segundo principio SOLID, el principio de abierto-cerrado (OCP, por sus […]

  6. El método científico aplicado al desarrollo de software - Tribalyte Technologies
    marzo 15, 2018 at 12:33 pm · Responder

    […] nos guiamos por las buenas prácticas de desarrollo (por ejemplo los principios SOLID de los que ya comenzamos a hablar), las guías de estilo de nuestro lenguaje o framework favorito (por ejemplo esta guía de estilo […]

Leave a reply Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

ELIGE UNA CATEGORÍA

  • Blockchain
  • Consejos tecnológicos
  • Desarrollo de aplicaciones
  • Desarrollo de software
  • Sistema embebido
  • Tecnologías
  • Uncategorized

Una compañía dedicada al desarrollo de apps, software y soluciones embebidas para empresas.

SOCIOS

Contacto

Glorieta de Quevedo 8 6º2
28015 Madrid (ESPAÑA)
Phone: +34 910 177 514 E-Mail: contact@tribalyte.com Web: www.tribalyte.com
Sello PYME INNOVADORA 21/01/2025
PYME INNOVADORA
Válido hasta el 21 de enero de 2025
escudo de MEIC 21/01/2025

AYUDA

  • Política de privacidad
  • Política de calidad
  • Política de seguridad
  • Términos de uso

CERTIFICACIONES

⠀⠀⠀⠀⠀⠀⠀⠀⠀

SUBVENCIONES

Tribalyte Technologies S.L. ha    conseguido la ayuda C007/20-ED de Red.es para el impulso y la promoción de actividades de I+i y para el fomento de la inversión empresarial para desarrollar el proyecto iPatia. Así mismo, valoramos muy positivamente la contribución del FEDER, principal fondo de la política de cohesión europea, por lo que supone de impulso a nuestro trabajo y en consecuencia al crecimiento económico y la creación de empleo de esta región y de España en su conjunto.
Esta página web utiliza cookies para mejorar su experiencia de usuario y para recabar estadísticas anónimas de uso. Aceptar Más información