Tag: liskov substitution

Aplicando Liskov Substitution Principle

Tiago TemporinDeixe um comentário

Dando início ao quarto post da série sobre SOLID, vamos falar um pouco sobre Liskov Substitution Principle.

Se você ainda não leu os outro posts da série, vou deixar os links aqui para que o faça.

Liskov Substitution, dos cinco princípios do SOLID, talvez seja o mais simples para se aplicar. Vamos relembrar o que diz esse princípio.

Classes “filhas” podem ser utilizadas no lugar das classes “pais” sem que o programa quebre. Em outras palavras, uma classe filha, mesmo com suas especificidades, deve manter o mesmo comportamento da classe pai.

Aqui, antes de continuar, vale fazer duas observações.

  1. Não existe orientação a objetos em Go, logo não temos classes.
  2. Como não temos classes, não temos herança.

Nesse momento você deve estar se perguntando. Se não temos classes e nem herança, como podemos aplicar esse princípio no Go?

Simples! Onde o princípio diz classe, pense em structs. Já onde diz herança, pense na técnica de embedding.

Ok! Agora que estamos alinhados, voltemos ao princípio.

Leia mais »
gray and brown concrete brick wall

O que é SOLID?

Tiago Temporin5 Comentários

SOLID é um acrônimo que representa cinco princípios no design de softwares orientados a objetos, sendo:

Single Responsability
Open-Closed
Liskov Substitution
Interface Segregation
Dependency Inversion Principle

Embora Go não seja uma linguagem orientada a objetos, ainda assim conseguimos utilizar os princípios de SOLID. Abaixo, vamos ver com mais detalhes cada um dos princípios.

Single Responsability

Uma classe ou, como é no caso do Go, uma struct deve ter uma única responsabilidade. Ou seja, cada struct deve ser projetada para executar uma determinada ação.

Pensando em um CRUD, é claro que você não terá uma struct para cada uma das ações (Create, Read, Update e Delete). Mas também não terá somente uma struct para lidar com todas as responsabilidades do package.

O ideal é ter pelo menos uma struct que represente a entidade do package. Uma para lidar com as transações com banco de dados, comumente chamada de repository. E outra para tratar as requests, independente se forem via API ou em algum modelo MVC.

Leia mais »