Categoria: SOLID

A importância de interfaces em arquiteturas de camadas

Tiago Temporin3 Comentários

Um código organizado é essencial para manter a facilidade em sua manutenção. Go, com sua simplicidade e eficiência, oferece diversos recursos para garantir uma arquitetura bem estruturada.

Um desses recursos é o uso de interfaces, que desempenham um papel fundamental na separação de responsabilidades e na criação de abstrações entre as camadas da aplicação.

Neste post, exploraremos como as interfaces podem ser aplicadas dentro de uma arquitetura em camadas, promovendo um código desacoplado, testável e flexível.

O que é uma arquitetura em camadas

Uma arquitetura em camadas é um padrão de design de software que divide a aplicação em diferentes camadas, onde cada uma tem uma responsabilidade específica.

Leia mais »

O que é e como aplicar Single Responsibility

Tiago TemporinDeixe um comentário

Chegamos ao último post da série sobre SOLID. Nele, vamos abordar como implementar o S, ou seja, Single Responsibility Principle.

Para você que chegou agora e ainda não viu os outros posts da série, vou deixar os links aqui:

Definindo Single Responsibility

Em algumas literaturas, vamos encontrar a definição de Single Responsibility como: “uma classe só pode ter uma única função”.

Embora seja totalmente válida essa definição, infelizmente ela pode levar à alguns equívocos, como por exemplo, implementar uma classe para cada operação com o banco de dados.

Equívoco totalmente aceitável. Afinal, uma classe que salva e busca dados em um banco de dados, não estaria tendo duas funções?!

Leia mais »

Como utilizar o princípio de Open-Closed

Tiago TemporinDeixe um comentário

Nesse penúltimo post sobre SOLID, vamos falar sobre a letra “O”, ou seja, o princípio Open-Closed. Antes de começar, caso você esteja chegando no blog agora, vou deixar aqui os links para os posts anteriores da série.

Voltando para o assunto desse post, vamos relembrar o que o princípio Open-Closed nos diz.

💡 Uma classe deve estar aberta para extensões, mas fechada para modificações. Ou seja, sempre que for necessário adicionar funcionalidades, devemos estender a classe ao invés de modificá-la.

Ao ler “…estender a classe…” na definição do princípio, provavelmente você pensou. “Vixi, não dá para aplicar em Go”, ou, “Fácil, só usar embedding nas structs”.

Leia mais »

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 »

O que é e como Interface Segregation é aplicada no Go

Tiago Temporin1 comentário

Dando continuidade na série sobre SOLID, nesse post vamos falar um pouco sobre Interface Segregation. Esse princípio talvez seja o mais utilizado na linguagem. Digo isso pois ele é fortemente utilizado nos packages core do Go, como por exemplo o package io.

Antes de continuar, se você chegou por aqui agora e ainda não viu os outros posts da série, convido-o a dar uma olhada.

Voltando à esse post, vamos relembrar o que diz o conceito de Interface Segregation.

💡 Uma classe não deve ser obrigada a implementar interfaces e métodos que não utilizará. Em outras palavras, é melhor ter 6 interfaces bem específicas, do que 2 mais genéricas.

Embora Go não implemente orientação a objetos, Interface Segregation pode ser aplicado na linguagem sem problemas. Isso devido a forma como structs e interfaces funcionam na linguagem.

Leia mais »

O que é e como aplicar Dependency Inversion Principle

Tiago Temporin2 Comentários

Nesse segundo post da série de posts sobre SOLID em Go, foquemos na letra ‘D’, ou seja, no Dependency Inversion Principle.

Se você não viu o primeiro post da série, recomendo a leitura para ter uma visão geral do que é SOLID.

Antes de ver como aplicar Dependency Inversion Principle em Go, vamos relembrar seu conceito.

Dependências devem ser abstraídas, para que os módulos de alto nível não dependam dos módulos de baixo nível.

Para facilitar o entendimento, vejamos um pouco de código. Para começar, um exemplo de como violar o Dependency Inversion Principle.

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 »