O Amigo do bom programador

Solid, o amigo do bom programador. 

SOLID é um conjunto de princípios de design de software introduzido por Robert C. Martin, também conhecido como Uncle Bob, nos anos 2000. Surgiu como uma resposta à necessidade de lidar com sistemas complexos e de grande escala, promovendo a coesão, flexibilidade e manutenção do código. Atualmente, os princípios SOLID são amplamente adotados na indústria de desenvolvimento de software, ajudando a criar sistemas mais robustos e escaláveis.

Nos dias atuais, é crucial entender os princípios SOLID, uma coleção de cinco princípios de design de software que visam criar sistemas mais compreensíveis, flexíveis e fáceis de manter. Vamos examinar cada um desses princípios e como eles podem ser aplicados no desenvolvimento de software.

1. Single Responsibility Principle (Princípio da Responsabilidade Única):

Este princípio afirma que uma classe deve ter apenas uma razão para mudar, ou seja, deve ter apenas uma responsabilidade. Isso promove a coesão, tornando o código mais fácil de entender e manter. Por exemplo, uma classe `UserService` deve ser responsável apenas por operações relacionadas a usuários, como criar, atualizar ou excluir usuários. Seguindo assim o princípio tratado.

-Responsável apenas por operações de usuário

public class UserService {

  public void createUser(User user) { /* implementação */ }

  public void updateUser(User user) { /* implementação */ }

  public void deleteUser(User user) { /* implementação */ }

}

2. Open/Closed Principle (Princípio Aberto/Fechado):

O princípio Open/Closed declara que uma classe deve ser aberta para extensão, mas fechada para modificação. Isso significa que você pode estender o comportamento da classe adicionando novas funcionalidades, mas sem modificar seu código fonte existente. Por exemplo, em vez de modificar a classe `Shape` para adicionar um novo método `calculateArea`, podemos criar uma nova classe `AreaCalculator` que implementa essa funcionalidade, mantendo assim o código de `Shape` inalterado.

- Classe aberta para extensão (pode adicionar novos tipos de formas)

public abstract class Shape {

  public abstract double calculateArea();

}

- Novo tipo de forma

public class Circle extends Shape {

  private double radius;

  public double calculateArea() { return Math.PI * radius * radius; }

}

3. Liskov Substitution Principle (Princípio da Substituição de Liskov):

Este princípio afirma que objetos de um subtipo devem ser substituíveis por objetos de seu tipo base sem interromper o funcionamento do programa. Em outras palavras, as subclasses devem ser substituíveis por suas superclasses sem afetar o comportamento esperado do programa. Por exemplo, se temos uma classe `Square` que é um subtipo de `Rectangle`, devemos poder substituir uma instância de `Square` por uma instância de `Rectangle` sem problemas.

- Substituição segura de subtipo

public class Rectangle {

  protected int width;

  protected int height;

  // getters e setters

}

- Subtipo substituível

public class Square extends Rectangle {

  @Override

  public void setWidth(int width) {

    this.width = width;

    this.height = width;

  }

  @Override

  public void setHeight(int height) {

    this.height = height;

    this.width = height;

  }

}

4. - Interface Segregation Principle (Princípio da Segregação de Interfaces)

O princípio da segregação de interfaces afirma que uma classe não deve ser forçada a depender de interfaces que ela não utiliza. Em vez disso, devem ser criadas interfaces específicas para os clientes. Isso evita que as classes tenham dependências desnecessárias e torna o sistema mais flexível. Por exemplo, em vez de ter uma única interface “UserInterface” com métodos para todas as operações de usuário, podemos dividir isso em interfaces menores, como “CreateUserInterface”, “UpdateUserInterface”, “DeleteUserInterface”, etc.

- Interfaces segregadas para operações específicas

public interface CreateUser {

  void createUser(User user);

}

public interface UpdateUser {

  void updateUser(User user);

}

public interface DeleteUser {

  void deleteUser(User user);

}

5. Dependency Inversion Principle (Princípio da Inversão de Dependência):

Este princípio afirma que módulos de alto nível não devem depender de módulos de baixo nível, mas ambos devem depender de abstrações. Além disso, abstrações não devem depender de detalhes, mas detalhes devem depender de abstrações. Isso promove o desacoplamento entre os componentes do sistema, facilitando a manutenção e a extensão do código. Por exemplo, em vez de uma classe de serviço depender diretamente de uma implementação de banco de dados específica, ela deve depender de uma interface abstrata que representa a funcionalidade do banco de dados.

- Alta camada depende de abstração

public class UserService {

  private UserRepository userRepository;

  public UserService(UserRepository userRepository) {

    this.userRepository = userRepository;

  }

  -métodos que utilizam userRepository

}

- Implementação de baixo nível

public class UserRepositoryImpl implements UserRepository {

- implementação dos métodos

}

-Abstração

public interface UserRepository {

-métodos de repositório

}

Seguir esses princípios SOLID pode ajudar a criar sistemas de software mais robustos, flexíveis e fáceis de manter, promovendo boas práticas de design e desenvolvimento de software.

#java #dio #Solid

By @OsvaldoCarvalho @OsvaldoNeto