O Princípio da Responsabilidade Única (Single Responsibility Principle — SRP) do SOLID

If you want to read this story in English, please click here.

Introdução

Neste artigo, irei abordar o primeiro princípio do SOLID, conhecido como o princípio de responsabilidade única (em inglês, Single Responsability Principle — SRP).

Primeiramente, o que é SOLID?

SOLID é um acrônimo que representa cinco princípios fundamentais de design e arquitetura de software orientados a objetos, identificados pelo Robert C. Martin (Uncle Bob), por volta dos anos 2000. O acrônimo SOLID foi introduzido por Michael Feathers, após observar que os cinco princípios poderiam se encaixar nessa palavra.

Seguir esses princípios pode resultar em um sistema mais compreensível, flexível e modular, que seja fácil de escalar, modificar e de testar.

Definição

O princípio da responsabilidade única (SRP), o primeiro dos cinco princípios do SOLID, é um conceito fundamental no desenvolvimento de software orientado a objetos.

Este princípio afirma que uma classe deve ter apenas uma razão para mudar, ou seja, deve ser responsável por apenas uma parte da funcionalidade do software.

Você deve aplicar este princípio não apenas em classes, mas em funções, módulos, etc.

Uma analogia para você compreender melhor

Imagine uma equipe em um restaurante. Nessa equipe, temos várias funções: cozinheiros, garçons, e o gerente. Cada um desses membros da equipe tem uma responsabilidade única. Os cozinheiros preparam a comida, os garçons servem a comida aos clientes, e o gerente cuida da administração do restaurante. Imagina que caos seria se uma única pessoa tentasse fazer todas essas tarefas, isso geraria um sistema totalmente ineficiente e confuso.

Da mesma forma, uma classe em um software deve ser especializada em uma única funcionalidade ou responsabilidade. Isso facilita a manutenção, a compreensão do código e ajuda na reutilização.

O SRP no desenvolvimento de software

Vamos observar um exemplo que viola o SRP. A classe abaixo lida com detalhes do usuário e ao mesmo tempo gerenciar a lógica de armazenamento desses detalhes.

class UserManager:
    def __init__(self, user_name, email):
        self.user_name = user_name
        self.email = email

    def change_user_email(self, new_email):
        # Lógica para mudar o email do usuário

    def save_user(self):
        # Lógica para salvar o usuário no banco de dados

Neste código, UserManager é responsável tanto pelo gerenciamento de detalhes do usuário como pela lógica de armazenamento (persistência de dados). Isso viola o SRP, pois temos mais de uma razão para modificar a classe.

Para corrigir a violação do SRP, podemos dividir a classe em duas: uma para gerenciar os detalhes do usuário e outra para lidar com a persistência dos dados.

class User:
    def __init__(self, user_name, email):
        self.user_name = user_name
        self.email = email

    def change_email(self, new_email):
        # Lógica para mudar o email do usuário

class UserDataStorage:
    def save_user(self, user):
        # Lógica para salvar o usuário no banco de dados

Vamos ver outro exemplo?

Abaixo, temos uma classe que gera relatórios sobre produtos e também os salva em um arquivo. Esta classe faz demais ao lidar com a formatação e a persistência dos dados.

class ProductReport:
    def __init__(self, products):
        self.products = products

    def generate_report(self):
        # Lógica para gerar relatório

    def save_report(self):
        # Lógica para salvar relatório

Para aderir ao SRP, podemos criar uma classe separada para a geração do relatório e outra para salvar o relatório em um arquivo.

class ProductReportGenerator:
    def __init__(self, products):
        self.products = products

    def generate_report(self):
        # Lógica para gerar relatório

class ReportSaver:
    def save_report(self, report):
        # Lógica para salvar relatório

Dicas para aplicar o SRP no seu projeto

1. Identifique as responsabilidades: Analise suas classes para identificar diferentes responsabilidades. Cada responsabilidade é um eixo de mudança potencial.
2. Divida e conquiste: Se uma classe tem mais de uma responsabilidade, considere dividí-la em classes menores, cada uma com sua própria responsabilidade.
3. Reutilização de código: Classes com uma única responsabilidade são mais fáceis de reutilizar, pois você pode usá-las em diferentes contextos sem trazer funcionalidades desnecessárias.
4. Testabilidade: Classes focadas em uma única responsabilidade são mais fáceis de testar, pois você não precisa lidar com múltiplas funcionalidades durante o teste de uma funcionalidade específica.

Conclusão

O princípio da responsabilidade única é essencial para o desenvolvimento de software sustentável e de alta qualidade. Classes, funções, módulos focados em uma única responsabilidade garantem a eficiência, a manutenibilidade e a clareza do código. Ao aplicar o SRP, você cria uma base sólida para uma arquitetura de software robusta, facilitando a evolução e a manutenção do seu projeto.

Muito obrigada por ter lido até aqui. Me encontre em outras redes sociais.