Skip to content

Reboredo.bit

Menu
  • Início
  • Sobre mim
  • Posts
Menu
solid principles

(S): Aplicando o “Princípio da Responsabilidade Única” com Typescript e Java

Posted on 25 de novembro de 202526 de novembro de 2025 by victoreboredo.dev@gmail.com

Entenda o Princípio da Responsabilidade Única (SRP) do SOLID: “Uma classe deve ter apenas uma razão para mudar.” Veja como refatorar classes com múltiplas responsabilidades (God Classes) usando exemplos em Java e TypeScript.


Conceitos

SOLID é um acrônimo que representa cinco princípios fundamentais da programação orientada a objetos, propostos por Robert C. Martin – o uncle Bob. Aqui você pode ler mais sobre o artigo dele.
Esses princípios têm como objetivo melhorar a estrutura e a manutenção do código, tornando-o mais flexível, escalável e fácil de entender. Tais princípios auxiliam o programador a criar códigos mais organizados, dividindo responsabilidades, reduzindo dependências, simplificando o processo de refatoração e promovendo a reutilização do código.

O “S” do acrônimo significa “Single Responsibility Principle”. A frase que o uncle bob utilizou para definir esse princípio foi:

“Uma classe deve ter uma, e apenas uma, razão para mudar.”

Segundo o Princípio da Responsabilidade Única, quando desenvolvemos nossas classes, precisamos ter em mente muito bem sua funcionalidade em particular. Se uma classe trata de duas funcionalidades a melhor coisa a fazer é dividi-la.
Ao aprender programação orientada a objetos, é comum atribuir múltiplas responsabilidades a uma única classe, criando as chamadas God Classes. Embora inicialmente pareça eficiente, essa abordagem mistura responsabilidades, tornando difícil alterar uma delas sem impactar as outras.

Aplicação prática

Para exemplificar uma aplicação prática desse problema criarei uma classe chamada UserService. Ela vai manipular diversas necessidades relacionados aos usuários.

Primeiro, vejamos a aplicação dessa classe sem utilizar o Princípio da Responsabilidade Única. Aqui nossa classe faz várias coisas: manipula dados do usuário, valida esses dados, e cria usuários no banco de dados.

Java

import java.util.ArrayList;
import java.util.List;

class User {
    private int id;
    private String name;
    private String email;

    public User(int id, String name, String email) {
        this.id = id;
        this.name = name;
        this.email = email;
    }

    @Override
    public String toString() {
        return "User{id=" + id + ", name='" + name + "', email='" + email + "'}";
    }
}

class UserService {
    private List<User> users = new ArrayList<>();

    public void addUser(String name, String email) {
        if (this.validateEmail(email)) {
            User newUser = new User(users.size() + 1, name, email);
            users.add(newUser);
            saveToDatabase(newUser);
        } else {
            throw new IllegalArgumentException("E-mail inválido");
        }
    }

    private boolean validateEmail(String email) {
        return email.matches("\\S+@\\S+\\.\\S+");
    }

    private void saveToDatabase(User user) {
        System.out.println("Salvando usuário no banco de dados " + user);
    }

    public List<User> getUsers() {
        return users;
    }

    public static void main(String[] args) {
        UserService userService = new UserService();
        userService.addUser("John Doe", "john@example.com");
        System.out.println(userService.getUsers());
    }
}

Typescript

type User = { id: number, name: string, email: string }

class UserService {
    private users: User[] = [];

    addUser(name: string, email: string) {
        if (this.validateEmail(email)) {
            const newUser = {
                id: this.users.length + 1,
                name: name,
                email: email
            };
            this.users.push(newUser);
            this.saveToDatabase(newUser);
        } else {
            throw new Error("E-mail inválido");
        }
    }

    private validateEmail(email: string): boolean {
        const emailRegex = /\S+@\S+\.\S+/;
        return emailRegex.test(email);
    }

    private saveToDatabase(user: User) {
        console.log("Salvando usuário no banco de dados", user);
    }

    getUsers() {
        return this.users;
    }
}

O principal problema que podemos encontrar aqui é a manutenção no código. Se houver uma mudança na lógica de validação ou na forma como os dados são salvos, isso afetará diretamente essa classe, dificultando a manutenção.

Agora, como podemos solucionar isso?
Devemos segregar nossa lógica contida na God Class “UserService” em diversas classes com funcionalidades bem definidas. Vejamos:

Java

import java.util.ArrayList;
import java.util.List;

// validador
class EmailValidator {
    public boolean validate(String email) {
        return email.matches("\\S+@\\S+\\.\\S+");
    }
}

// Repositório que manipula os dados no banco de dados
class UserRepository {
    private List<User> users = new ArrayList<>();

    public void save(User user) {
        System.out.println("Salvando usuário no banco de dados " + user);
        users.add(user);
    }

    public List<User> getAll() {
        return users;
    }
}

// Aplicamos as regras do domain com injeção de dependências
class UserService {
    private EmailValidator emailValidator;
    private UserRepository userRepository;

    public UserService(EmailValidator emailValidator, UserRepository userRepository) {
        this.emailValidator = emailValidator;
        this.userRepository = userRepository;
    }

    public void addUser(String name, String email) {
        if (emailValidator.validate(email)) {
            User newUser = new User(userRepository.getAll().size() + 1, name, email);
            userRepository.save(newUser);
        } else {
            throw new IllegalArgumentException("E-mail inválido");
        }
    }

    public List<User> getUsers() {
        return userRepository.getAll();
    }
}

Typescript

// validador
class EmailValidator {
    validate(email: string): boolean {
        const emailRegex = /\S+@\S+\.\S+/;
        return emailRegex.test(email);
    }
}

// Repositório que manipula os dados no banco de dados
class UserRepository {
    private users: { id: number, name: string, email: string }[] = [];

    save(user: { id: number, name: string, email: string }) {
        console.log("Salvando usuário no banco de dados", user);
        this.users.push(user);
    }
    getAll() {
        return this.users;
    }
}

// Aplicamos as regras do domain com injeção de dependências
class UserService {
    constructor(
        private emailValidator: EmailValidator,
        private userRepository: UserRepository
    ) {}

    addUser(name: string, email: string) {
        if (this.emailValidator.validate(email)) {
            const newUser = {
                id: this.userRepository.getAll().length + 1,
                name: name,
                email: email
            };
            this.userRepository.save(newUser);
        } else {
            throw new Error("E-mail inválido");
        }
    }

    getUsers() {
        return this.userRepository.getAll();
    }
}

Aplicar o Princípio da Responsabilidade Única (Single Responsibility Principle) é crucial para a criação de software robusto e escalável. Ao garantir que cada classe tenha apenas uma responsabilidade, reduzimos a complexidade do código, facilitamos sua manutenção e refatoração, e minimizamos o risco de erros. Esse princípio é fundamental para manter a qualidade e a longevidade do projeto, promovendo um design mais limpo e eficiente.

Navegação de Post

← Linguagem de programação para além do código
(O): Aplicando o “Princípio do Aberto/Fechado” com Typescript e Java →

2 thoughts on “(S): Aplicando o “Princípio da Responsabilidade Única” com Typescript e Java”

  1. Pingback: (O): Aplicando o “Princípio do Aberto/Fechado” com Typescript e Java - Reboredo.bit
  2. Pingback: Princípio da Responsabilidade Única - Reboredo.bit

Deixe um comentário Cancelar resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Recent Posts

  • Microsserviços: 5 Lições Aprendidas — Um Olhar Arquitetural
  • 5 Pilares financeiros que destacam negócios de alto valor
  • Princípio da Responsabilidade Única e as implicações na Orientação a Objetos e Arquitetura de Software
  • (D): Aplicando o “Princípio da Inversão de Dependências” com Typescript e Java
  • (I): Aplicando o “Princípio da Segregação da Interface” com Typescript e Java

Archives

  • novembro 2025

Categories

  • Empreendimento (1)
  • Engenharia (9)
  • Finança (2)
  • Java (6)
  • Liderança (1)
  • Orientação a Objetos (8)
  • Programação (9)
  • Programação Estruturada (2)
  • Typescript (8)
© 2025 Reboredo.bit | Powered by Minimalist Blog WordPress Theme