Chegamos na metade do caminho da série de posts a respeito do S.O.L.I.D, caso ainda não tenha lido as duas primeiras 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
Nesta série de posts sobre o uso do SOLID no Swift, irei abordar cada um dos princípios de forma única. Portanto, sem mais delongas, vamos continuar a montagem desse quebra-cabeças com o princípio que costuma gerar mais dificuldades de entendimento, falaremos sobre o L: Liskov Substitution Principle. O que em português conhecemos como o Princípio da substituição de Liskov.
Mas, o que é esse princípio?
No seu livro “Princípios, Padrões e Práticas Ágeis”, uncle Bob escreveu a seguinte definição para este LSP (Liskov Substitution Principle):
Os subtipos devem ser substituíveis pelos seus tipos de base.
Essa foi a definição mais simples que já vi, até hoje, deste princípio. No caso de uso que estamos explorando nesta série de posts, “Realizar Login”, vamos identificar a aplicação do LSP.
Analisando o código
LoginViewModel.swift – revision 3
final class LoginViewModel {
weak var worker: LoginWorkerProtocol?
init(worker: LoginWorkerProtocol? = LoginInDeviceWorker()) {
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 ver que a estrutura atual da classe LoginViewModel já segue o princípio da substituição de Liskov, pois utiliza um protocolo (LoginWorkerProtocol) que pode ser implementado de diversas maneiras. Cada implementação pode ser usada de forma intercambiável sem alterar o comportamento do método makeLogin.
Dessa forma, qualquer classe filha de LoginWorkerProtocol pode ser injetada na classe LoginViewModel fazendo com que o método makeLogin continue funcionando como esperado, sem a necessidade de saber como o requestLogin (método definido na base) é feito pelo worker.
Conclusão
Não sei se você percebeu, mas o LSP está andando de mãos dadas com o OCP após ser realizado o refactoring da LoginViewModel para atender ao OCP. Neste post não tivemos alterações na view model, apenas analisamos o código e identificamos que ela já está de acordo com o LSP.
Podemos também utilizar este princípio para identificar quando uma classe não precisa, ou não deve, ser derivada de uma classe base.
Vale ressaltar que neste post consideramos apenas o LSP, porém, vimos que os princípios estão se complementando contudo que avançamos no entendimento de cada um deles. Nos próximos posts da série iremos continuar aprimorando esse caso de uso “Realizar Login”, para que esteja em conformidade com todos os princípios.
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.
Obs.: alguns padrões de projeto e outros princípios estão sendo utilizados nesta série de posts, porém, iremos abordar sobre eles em outra série de postagens, em breve.
Referências
Princípios, Padrões e Práticas Ágeis em C#
The S.O.L.I.D Principles in Pictures
O que é SOLID: O guia completo para você entender os 5 princípios da POO