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.
Esses 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 esse princípio, 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 Single Responsability Principle. 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", "[email protected]");
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.