Criando uma lógica de Login usando SOLID no Swift – Parte 5 de 5

Este é o último post da série a respeito do S.O.L.I.D, caso ainda não tenha lido as demais partes, elas podem ser encontradas aqui:

Criando uma lógica de Login usando SOLID no Swift – Parte 1 de 5

Criando uma lógica de Login usando SOLID no Swift – Parte 2 de 5

Criando uma lógica de Login usando SOLID no Swift – Parte 3 de 5

Criando uma lógica de Login usando SOLID no Swift – Parte 4 de 5

Nesta série de posts sobre o uso do SOLID no Swift, estou abordando cada um dos princípios de forma única. Portanto, sem mais delongas, vamos finalizar a montagem deste quebra-cabeças com o princípio que costuma ser usado de forma natural, sem que a galera perceba, falaremos sobre o D: Dependency Inversion Principle. O que em português conhecemos como o Princípio da Inversão de Dependência.

Mas, o que é esse princípio?

No artigo A Little Architecture, do Uncle Bob, define que o DIP (Dependency inversion principle) deve ter o seguinte comportamento: regras/módulos de baixo nível devem depender de regras/módulos de alto nível. No já citado livro, do também Uncle Bob, “Princípios, Padrões e Práticas Ágeis”, ele cita:

A: Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações.
B: As abstrações não devem depender de detalhes. Os detalhes devem depender das abstrações.

A segunda citação (B) complementa a primeira ao declarar que essas abstrações não devem ser influenciadas pelos detalhes de implementação, mas sim que os detalhes específicos devem ser subordinados às abstrações.

Vamos analisar o código que construímos até aqui para validar se ele já está de acordo com este princípio.

Analisando o código

final class LoginViewModel {
  weak var worker: LoginWorkerProtocol?
  
  init(worker: LoginWorkerProtocol?) {
    self.worker = worker
  }
  
  func makeLogin(_ loginRequest: LoginRequest, completion: @escaping (Result<Bool, ApiError>) -> Void) {
    guard loginRequest.isValid() else {
      completion(.failure(.invalidCredentials))
      return
    }
    
    worker?.requestLogin(with: loginRequest, completion: completion)
  }
}

Podemos notar que, nossa classe LoginViewModel, depende de um LoginWorkerProtocol para realizar a requisição do login. Isso demonstra que independente de qual seja a implementação desse requestLogin, o método na view model continuará funcionando normalmente pois, esta, depende apenas da interface (protocol) e não da classe concreta. Neste caso podemos considerar que o LoginWorkerProtocol é o nível mais baixo na arquitetura, o que nos permite entender que o DIP está sendo respeitado nessa estrutura. A classe LoginViewModel (alto nível), está dependendo da abstração LoginWorkerProtocol, que por sua vez é implementada por alguma classe baixo nível.

Conclusão

Ao aplicar os princípios SOLID no nosso código, fazemos com que ele seja mais modular e sustentável, no sentido de que podemos evoluir a aplicação com baixo risco, uma vez que as classes implementarão cada um dos princípios citados nesta série. Vale ressaltar que, os princípios podem ser usados em conjunto ou, também, de formas separadas, tudo de acordo com a realidade e a necessidade do código.

Estes princípios também podem ser combinados com outros princípios e padrões para deixar o código cada vez mais legível e sustentável.

Em breve irei iniciar uma série de posts sobre padrões de projetos.

Se você chegou até aqui, obrigado pela atenção.

Quaisquer dúvidas, deixe nos comentários para enriquecermos o aprendizado.

Compartilhe este post com outros devs para que possamos trocar mais experiências.

Referências:

Princípios, Padrões e Práticas Ágeis em C#

A Little Architecture

The S.O.L.I.D Principles in Pictures

O que é SOLID: O guia completo para você entender os 5 princípios da POO