Forem: Rafael Honório

Understanding SOLID once and for all | Part 04 - (ISP)

Rafael Honório — Wed, 06 Aug 2025 02:43:51 +0000

Hey folks, continuing the series about SOLID, today we will talk about the Interface Segregation Principle (ISP). In my view, this is the easiest concept of the five principles. The name already says a lot about what we will discuss, and I will also share some cool insights about interfaces.

Summary

The idea of an interface appeared at the end of the eighties, after languages like Simula and Smalltalk had already introduced most of the basics we know today as object-oriented programming.

Bertrand Meyer formally presented the interface concept in his book Object Oriented Software Construction, published in 1988. In that book, he defined the concept of contracts between software components in the Eiffel language. Since then, these techniques have been adopted in many other languages, such as Java, C#, and Ruby.

The goal of creating a contract (interface) is to show that a certain module has common behaviour that can be reused in different contexts. Classic examples are:

Interaction with a database
Interaction with cache
Interaction with a message broker
Interaction with subtypes (inheritance)

All those situations share two ideas:

There is a base behaviour that repeats in all or almost all cases.
Each implementation will be used in many places in your code.

The Interface Segregation Principle says:

No client should be forced to depend on methods it does not use.

So an interface should define behaviour for a specific area of your software, making the code more cohesive and less coupled.

Examples

type Printer interface {
  Print()
  PrintColorFull()
  Fax()
  Scan()
}

type BasicPrinter struct{}
func (BasicPrinter) Print() { fmt.Println("Printing...") }

In this case, the other methods are missing, so it breaks ISP.

A better approach is to create specific interfaces:

type Printable interface { Print() }
type PrintableColor interface { PrintColorFull() }
type Scannable interface { Scan() }
type Faxable interface { Fax() }

type BasicPrinter struct{}
func (BasicPrinter) Print() { fmt.Println("Printing...") }

Now, ISP is respected. In short, we have:

All interfaces defined
A struct called BasicPrinter
Implementation of Printable in BasicPrinter by adding the Print() method

Note: In Go, these links are implicit.

Below is a similar example in Elixir. The language allows generic return types, so you can implement the behaviour in other modules without returning the same data type.

In Elixir an “interface” is called a behavior or callback.

defmodule MultiFunctionDevice do
  @callback print() :: any()
  @callback fax() :: any()
  @callback scan() :: any()
end

defmodule SimplePrinter do
  @behaviour MultiFunctionDevice
  def print, do: IO.puts("Printing")
  def fax, do: :not_implemented
  def scan, do: :not_implemented
end

The same idea applies here. Even though the function exists, returning :not_implemented or leaving empty functions shows that the interface is poorly designed and still breaks the principle.

defmodule PrinterOnly do
  @callback print() :: any()
end

Same strategy: split the interface into smaller ones.

Conclusion

Interfaces have no mystery. ISP pushes us to split big interfaces into smaller cohesive contexts, which helps in many cases like:

Inheritance between objects
Interaction with external services (cache, message broker, database)
Structured error handling

What we get:

Less coupling
More cohesive code
Code that adapts better to change

Reference code

Elixir examples: solid_elixir_examples
Go examples: solid-go-examples

I hope the concepts are clear. If you still have questions, feel free to leave a comment.

Entendendo SOLID de uma vez por todas | Parte 04 - (ISP)

Rafael Honório — Wed, 06 Aug 2025 02:32:08 +0000

Hey pessoal, continuando a série sobre SOLID, hoje vamos falar sobre o Interface Segregation Principle (ISP). Esse é, na minha opinião, o conceito mais tranquilo dos cinco princípios. O próprio nome já entrega bastante sobre o que vamos conversar, e ainda vou aproveitar para trazer alguns insights interessantes sobre interfaces.

Resumo

O conceito de interface surgiu no final da década de 80, após as linguagens Simula e Smalltalk já terem introduzido boa parte dos fundamentos que a gente entende hoje como orientação a objetos.

Foi o Bertrand Meyer quem apresentou formalmente o conceito de interface em seu livro Object-Oriented Software Construction, publicado em 1988. Nele, Meyer definiu a ideia de contratos entre componentes de software na linguagem Eiffel, e desde então essas técnicas e conceitos passaram a ser aplicados amplamente em outras linguagens como Java, C#, Ruby, entre outras.

A intenção de criar um contrato (interface) parte da ideia de que determinado módulo do software possui características comuns que podem ser reaproveitadas em vários contextos diferentes. Exemplos clássicos disso seriam:

Interação com banco de dados
Interação com cache
Interação com message broker
Interação com subtipos (herança)

Todas essas situações tem em comum dois pontos em comum;
1 - Existe uma base de comportamento que vai se repetir em todas, ou quase todas as vezes.
2 - Cada implementação vai ser usada em vários pontos do seu código.

A definição de Interface Segregation Principle (IPS) é:

Nenhum cliente deve ser forçado a depender de métodos que não utiliza.

Ou seja, a tendência é que interface defina comportamentos de uma determinada área do seu software com intuíto de criar mais coesão e desacoplamento entre os módulos.

Vamos aos exemplos

type Printer interface {
  Print()
  PrintColorFull()
  Fax()
  Scan()
}

type BasicPrinter struct{}
func (BasicPrinter) Print() { fmt.Println("Printing...") }

nesse caso não existe implementação dos outros métodos, isso viola o ISP.

O correto seria ter interfaces específicas para esse caso

type Printable interface { Print() }
type PrintableColor interface { PrintColorFull() }
type Scannable interface { Scan() }
type Faxable interface { Fax() }

type BasicPrinter struct{}
func (BasicPrinter) Print() { fmt.Println("Printing...") }

Agora não infringe o ISP, talvez fique um pouco complicado de entender para quem não familiaridade com Golang mas o que aconteceu nesse código foi:

Definição de todas interfaces
Definição de uma struct chamada BasicPrinter
Implementação da interface Printable na struct BasicPrinter ao criar a func que é um método Print()

Obs: Esses vínculos acontecem de forma implícita em Go.

A seguir, apresento outro exemplo em Elixir que reproduz a mesma ideia. A diferença é que a linguagem permite retornar tipos genéricos, o que implica implementar esses comportamentos em outros módulos sem necessariamente devolver o mesmo tipo de dado.

Em Elixir, a implementação de uma “interface” recebe o nome de behavior ou callback.

defmodule MultiFunctionDevice do
  @callback print() :: any()
  @callback fax() :: any()
  @callback scan() :: any()
end

defmodule SimplePrinter do
  @behaviour MultiFunctionDevice
  def print, do: IO.puts("Printing")
  def fax, do: :not_implemented
  def scan, do: :not_implemented
end

A mesma ideia se aplica aqui. Mesmo que a função seja implementada, o retorno é :not_implemented. Devolver :not_implemented ou criar funções vazias é um baita sinal de que a interface foi mal pensada e está quebrando o princípio, mesmo respeitando a assinatura das funções da interface.

defmodule PrinterOnly do
  @callback print() :: any()
end

A abordagem é a mesma, dividir a interface outras específicas.

Conclusão

Não existe mistério quando falamos de interfaces. O ISP defende a divisão de grandes interfaces em contextos menores e mais coesos, algo que vale em várias situações como:

Herança entre objetos
Interações com contextos externos (cache, message broker, banco de dados)
Erro handling estruturado

Com isso a gente ganha:

Redução no acoplamento
Código mais coeso
Código mais flexível a mudanças

Código de Referência

Exemplos em Elixir: solid_elixir_examples
Exemplos em Go: solid-go-examples

Espero que tenha ficado claro os conceitos, se caso ficou alguma dúvida, fique a vontade para deixar um comentário.

Understanding SOLID once and for all | Part 03 - (LSP)

Rafael Honório — Tue, 22 Jul 2025 02:50:05 +0000

Motivation

Hey everyone, how’s it going? This is the third post of the series where I’m sharing my experience with SOLID. In this article, we’re going to understand a bit more about the Liskov Substitution Principle (LSP) and see some examples.

This might be the hardest concept to understand, but I’ll try to explain it in a simple way to make everything clear.

Summary

This concept was created by Barbara Liskov and Jeannette Wingin 1994 in a paper called "A Behavioral Notion of Subtyping" and the definition says:

Subtypes must be replaceable for their base types without affecting the correctness of the program.

In short, you should be able to replace a base type with its subtype, since the subtype has all the characteristics of the base type, and this shouldn't break the current flow.

Example

Imagine the following situation: we have two classes. A parent class with some properties and methods, and a child class that extends it. If we try to replace the parent class with the child class somewhere in the code, everything should work fine. Here's an example in the image:

The example shows a function that saves the information. In theory, it works because the type substitution doesn’t affect how the code behaves. It respects the contract, whether we’re using inheritance or interface.

LSP says that objects of the child class should be usable in place of objects of the parent class without changing the correct behavior of the program. Let’s check that in the example:

Parent Class Contract:
- The parent class defines properties xpto_01 and xpto_02. The function save_parent() depends on these methods to work correctly.
Child Class Behavior:
- The child class inherits xpto_01 and xpto_02 and adds a new one: xpto_03. If the save_parent() function doesn’t use xpto_03, and the other two properties are implemented in the same way, then it’s all good.
Substitution in Function:
- If save_parent() only uses xpto_01 and xpto_02, and the child class implements them correctly, the substitution works. The new method xpto_03 doesn’t affect the contract.

LSP in practice

Now let’s look at a Go example with the same idea:

In this case, we have an interface called Salvable that defines a contract for saving data. A struct User (like the parent class) and a struct PremiumUser (like the child class) both implement this interface. The child struct has an extra field.

package main

import "fmt"

// Salvable interface defines the base contract
type Salvable interface {
    Save() string
}

type User struct {
    Name string
    Age int
}

// User implements the Salvable interface
func (u *User) Save() string {
    return fmt.Sprintf("Saving user: Name=%s, Age=%d", u.Name, u.Age)
}

// PremiumUser extends User behavior
type PremiumUser struct {
    User
    PremiumLevel int
}

func (pu *PremiumUser) Save() string {
    // Keeps the contract, adding extra info
    return fmt.Sprintf("Saving premium user: Name=%s, Age=%d, PremiumLevel=%d", pu.Name, pu.Age, pu.PremiumLevel)
}

// Function that uses the Salvable interface
func SaveProcess(s Salvable) {
    result := s.Save()
    fmt.Println(result)
}

func main() {
    user := &User{Name: "Jonas", Age: 30}
    premiumUser := &PremiumUser{User: User{Name: "Mary", Age: 25}, PremiumLevel: 3}

    fmt.Println("Processing User:")
    SaveProcess(user)

    fmt.Println("Processing PremiumUser:")
    SaveProcess(premiumUser)
}

Expected output:

Processing User:
Saving user: Name=Jonas, Age=30
Processing PremiumUser:
Saving premium user: Name=Mary, Idade=25, PremiumLevel=3

But what happens if we break the LSP?

package main

import "fmt"

type Salvable interface {
    Save() string
}


type User struct {
    Name string
    Age int
}

func (u *User) Save() string {
    return fmt.Sprintf("Saving user: Name=%s, Age=%d", u.Name, u.Age)
}

type PremiumUser struct {
    User
    PremiumLevel int
}

func (pu *PremiumUser) Save() string {
    // Restriction: only save if PremiumLevel > 0
    if pu.PremiumLevel <= 0 {
        return "Error: Invalid PremiumLevel"
    }
    return fmt.Sprintf("Saving premium user: Name=%s, Age=%d, PremiumLevel=%d", pu.Name, pu.Age, pu.PremiumLevel)
}

func SaveProcess(s Salvable) {
    result := s.Save()
    fmt.Println(result)
}

func main() {
    user := &User{Name: "Jonas", Age: 30}
    premiumUser := &PremiumUser{User: User{Name: "Mary", Age: 25}, PremiumLevel: 3}

    fmt.Println("Processing User:")
    SaveProcess(user)

    fmt.Println("Processing PremiumUser:")
    SaveProcess(premiumUser)
}

Expected output:

Processing User:
Saving user: Name=Jonas, Age=30
Processing PremiumUser:
Error:: Invalid PremiumLevel

In this case, we have some problems:

The PremiumUser class adds a restriction (PremiumLevel > 0) that doesn’t exist in Salvable or in User.
The SaveProcess function expects Save() to always return a success message, but now it can return an error.
This breaks the LSP because replacing Salvable with PremiumUser changes the expected behavior by adding a condition that doesn’t exist in the contract.

Conclusion

In general, this principle helps us reflect on how modules implement behaviors like methods, callbacks, or interfaces. If you need to “force” an implementation just to respect a contract, or change how a method behaves in a subtype, or if replacing types breaks your system, that’s a strong sign the LSP is being violated.

That’s it for now! If you have any questions, leave them in the comments. See you in the next one!

Elixir examples: solid_elixir_examples
Go examples: solid-go-examples

Entendendo SOLID de uma vez por todas | Parte 03 - (LSP)

Rafael Honório — Mon, 21 Jul 2025 23:57:33 +0000

Motivação

Fala pessoal de boas? esse é o terceito texto da série que estou compartilhando minha experiência com SOLID. neste artigo, vamos entender um pouco melhor Liskov Substitution Principle (LSP) e ver alguns exemplos.

Talvez esse seja o conceito mais difícil de entender, mas vou tentar exemplificar da forma mais simples possível para não deixar dúvidas de quanto a aplicação.

Breve resumo

Esse conceito foi cunhado pela Barbara Liskov e Jeannette Wing em 94 em um artigo chamado "A Behavioral Notion of Subtyping" e a definição diz:

Subtipos devem poder ser usados no lugar de seus tipos base, sem alterar a correção do programa.

Em tese, você deve conseguir substituir um tipo base pelo subtipo dado que, o subtipo contêm todas as caracteristicas do tipo base, e isso não deve quebrar o fluxo atual.

Exemplo

Imagine a seguinte situção, existem duas classes, uma classe pai que tem propriedades e metódos, a classe filha implementa a classe pai, se caso a gente fosse substituir a classe pai pela filha em alguma implementacão, nosso código não deveria quebrar, segue o exemplo em imagem:

No exemplo mostra uma função que salva essas informações e em tese, a função funcionaria por que a substituição dos tipos não influenciaria no comportamento interno visto que respeita o contrato se considerar a herança ou interface.

O LSP exige que objetos da classe filha possam substituir objetos da classe pai sem alterar o comportamento correto do programa. Vamos verificar se isso é válido no exemplo:

Contrato da Classe Pai:
- A classe pai define as propriedades xpto_01 e xpto_02. A função save_pai() depende desses métodos ou atributos para funcionar corretamente.
Comportamento da Classe Filha:
- A classe filha herda xpto_01 e xpto_02 e adiciona xpto_03. Se xpto_03 não for chamado pela função save_pai() (ou seja, a função só usa xpto_01 e xpto_02), a substituição da classe pai pela filha não deve causar problemas, desde que a implementação de xpto_01 e xpto_02 na filha seja consistente com a do pai.
Substituição na Função:
- Se save_pai() for projetada para trabalhar apenas com os atributos ou métodos da classe pai (xpto_01 e xpto_02), e a classe filha os implementa da mesma forma, a substituição funciona. A adição de xpto_03 não afeta o contrato, pois a função não depende dele.

LSP na prática

Vamos seguir para um exemplo em Golang seguindo a mesma linha de raciocinio:

Neste exemplo, temos umas interface Salvavel que define um contrato para salvar dados. Umas struct Usuario (equivalente à classe pai) e uma struct UsuarioPremium (equivalente à classe filha) implementam essa interface, adicionando uma propriedade extra na filha.

package main

import "fmt"

// Interface Salvavel define o contrato base
type Salvavel interface {
    Salvar() string
}

type Usuario struct {
    Nome string
    Idade int
}

// Usuario implementa a interface Salvavel
func (u *Usuario) Salvar() string {
    return fmt.Sprintf("Salvando usuario: Nome=%s, Idade=%d", u.Nome, u.Idade)
}

// UsuarioPremium estende o comportamento do Usuario
type UsuarioPremium struct {
    Usuario
    NivelPremium int
}

func (up *UsuarioPremium) Salvar() string {
    // Mantém o contrato da interface, adicionando informações extras
    return fmt.Sprintf("Salvando usuario premium: Nome=%s, Idade=%d, NivelPremium=%d", up.Nome, up.Idade, up.NivelPremium)
}

// Função que usa a interface Salvavel (equivalente à "save_pai")
func ProcessarSalvar(s Salvavel) {
    resultado := s.Salvar()
    fmt.Println(resultado)
}

func main() {
    // Instâncias
    usuario := &Usuario{Nome: "João", Idade: 30}
    usuarioPremium := &UsuarioPremium{Usuario: Usuario{Nome: "Maria", Idade: 25}, NivelPremium: 3}

    // Testando substituição
    fmt.Println("Processando Usuario:")
    ProcessarSalvar(usuario) // Funciona como esperado

    fmt.Println("Processando UsuarioPremium:")
    ProcessarSalvar(usuarioPremium) // Também funciona, respeitando o LSP
}

saída esperada:

Processando Usuario:
Salvando usuario: Nome=João, Idade=30
Processando UsuarioPremium:
Salvando usuario premium: Nome=Maria, Idade=25, NivelPremium=3

e se caso a gente violasse o LSP?

package main

import "fmt"

// Interface Salvavel define o contrato base
type Salvavel interface {
    Salvar() string
}

type Usuario struct {
    Nome string
    Idade int
}

// Usuario implementa a interface Salvavel
func (u *Usuario) Salvar() string {
    return fmt.Sprintf("Salvando usuario: Nome=%s, Idade=%d", u.Nome, u.Idade)
}

// UsuarioPremium com restrição
type UsuarioPremium struct {
    Usuario
    NivelPremium int
}

func (up *UsuarioPremium) Salvar() string {
    // Restrição: só salva se NivelPremium > 0
    if up.NivelPremium <= 0 {
        return "Erro: NivelPremium inválido"
    }
    return fmt.Sprintf("Salvando usuario premium: Nome=%s, Idade=%d, NivelPremium=%d", up.Nome, up.Idade, up.NivelPremium)
}

// Função que usa a interface Salvavel
func ProcessarSalvar(s Salvavel) {
    resultado := s.Salvar()
    fmt.Println(resultado)
}

func main() {
    usuario := &Usuario{Nome: "João", Idade: 30}
    usuarioPremium := &UsuarioPremium{Usuario: Usuario{Nome: "Maria", Idade: 25}, NivelPremium: 0}

    fmt.Println("Processando Usuario:")
    ProcessarSalvar(usuario) // Funciona: "Salvando usuario: Nome=João, Idade=30"

    fmt.Println("Processando UsuarioPremium:")
    ProcessarSalvar(usuarioPremium) // Quebra o comportamento esperado: "Erro: NivelPremium inválido"
}

saída esperada:

Processando Usuario:
Salvando usuario: Nome=João, Idade=30
Processando UsuarioPremium:
Erro: NivelPremium inválido

Nesse caso acontece algumas situações não tão legais:

A classe UsuarioPremium adiciona uma restrição (NivelPremium > 0) que não existe na interface Salvavel nem em um Usuario.
A função ProcessarSalvar espera que Salvar() sempre retorne uma string de sucesso (com dados salvos), mas UsuarioPremium pode retornar um erro, quebrando o contrato implícito.
Isso viola o LSP porque a substituição de Salvavel por UsuarioPremium altera o comportamento esperado, introduzindo uma pré-condição que a interface não define.

Conclusão

No geral, esse princípio nos faz refletir sobre como os módulos estão implementando comportamentos, como métodos, callbacks e behaviors. Se for preciso "forçar" alguma implementação apenas para cumprir um contrato, alterar o retorno do contrato no subtipo, ou se a substituição de tipos acaba quebrando o funcionamento do sistema, é um sinal claro de que o LSP está sendo violado.

No mais é isso, qualquer dúvida deixe nos comentários, nos vemos na próxima!

Exemplos em Elixir: solid_elixir_examples
Exemplos em Go: solid-go-examples

Understanding SOLID once and for all | Part 02 - (OCP)

Rafael Honório — Wed, 16 Jul 2025 22:17:11 +0000

Motivation

Hey folks, how’s it going?

This is the second post in the series where I’m sharing my real-world experience with SOLID principles in a straightforward and down-to-earth way. In the first post, I talked about SRP and showed how small violations can make code maintenance harder. If you haven’t seen it yet, go check it out!

Today, we’re taking a step further with the Open–Closed Principle (OCP), the pillar that teaches us how to extend behavior without modifying what's already working.

Brief Overview

This term was coined by Bertrand Meyer in 1988 and popularized by Robert C. Martin (Uncle Bob). OCP is usually summarized by the phrase:

“Software entities should be open for extension, but closed for modification.”

At first glance, it seems paradoxical how something can be open for extension and closed for modification at the same time? The secret lies in one word: abstractions (interfaces, behaviours, callbacks).

As systems grow larger, both in file size and complexity, it becomes essential to use abstractions to expand behavior without changing the core implementation. In other words, the base code “never changes.”

Example – A function that calculates tax on a product

Can the calculation change? Yes, but it's unlikely.
What are the variables? Product value + Tax rate
Which of these might change? Tax rate

These are the types of questions I ask myself to identify variation points in the implementation. In this case, the how to calculate is unlikely to change, but the tax rate might.

Here's a typical implementation of such a calculation:

function calculate(price), do:
  price * @tax_rate or 0.10

The pseudo-code above is a simple and direct implementation. However, it has a downside: every time the tax rate changes, we have to modify the function, which can cause unintended issues elsewhere in the system.

Now, imagine we did this instead:

function calculate_tax(price, tax_function), do:
  tax_function(price)

In this case, we don’t need to change the core logic when requirements change. We pass a function as a parameter to calculate the new value. This allows us to implement new features through new modules or classes without touching already-tested code, thus expanding functionality safely.

OCP in Practice

1. Discount Strategy in Go

Excerpt from the solid-go-examples repository:

// Interface that defines the variation point
type Discount interface {
    Apply(price float64) float64
}

// No discount implementation
type NoDiscount struct{}
func (NoDiscount) Apply(price float64) float64 { return 0 }

// Percentage discount implementation
type PercentageDiscount struct{}
func (PercentageDiscount) Apply(price float64) float64 { return price * 0.1 }

// Core function that doesn’t change when new discounts are added
func CalculatePrice(price float64, d Discount) float64 {
    return price - d.Apply(price)
}

Usage in main.go:

noDisc := NoDiscount{}
percentageDisc := PercentageDiscount{}

fmt.Println(CalculatePrice(100, noDisc)) // 100
fmt.Println(CalculatePrice(100, percentageDisc)) // 90

Why does this follow OCP?

CalculatePrice is closed for modification—we didn’t touch it to add PercentageDiscount. At the same time, the system is open for extension because we can add new types that implement Discount (e.g., BlackFridayDiscount) at any time.

2. Payment Processor in Elixir

File: 02_open_closed_principle.ex from the solid_elixir_examples repo:

defmodule PaymentProcessor do
  def process(order, tax_calculator) do
    tax = tax_calculator.(order)
    total = order.amount + tax
    {:ok, %{order: order, tax: tax, total: total}}
  end
end

# Different tax rules without changing the module
PaymentProcessor.process(%{amount: 100}, fn o -> o.amount * 0.1 end)
PaymentProcessor.process(%{amount: 100}, fn o -> o.amount * 0.2 end)

Why does this follow OCP?

PaymentProcessor delegates tax calculation to a function received as a parameter. When a new regulation appears, we just create another function (or module) and pass it in—no need to touch the processing logic.

Tips for Adopting OCP

Changing Situation	OCP-Friendly Approach
New payment methods	Define a `PaymentGateway` interface and implement new adapters without altering existing ones.
New pricing rules	Use callback functions or the strategy pattern to encapsulate logic—this improves maintainability and testability.
New reports	Apply the Template Method pattern or use plug-ins to generate reports instead of editing the base class.

Golden tip: Find the variation point in your code—this is usually the part that needs to be encapsulated.

Signs of OCP Violation

Growing switch/case blocks whenever new data types appear.
Tests breaking in a cascade when only one requirement changes.
Constant changes in the core domain (more internal rule changes = greater need for OCP).

Conclusion

Applying the Open–Closed Principle isn’t about “never touching code again.” It’s about minimizing high-risk changes and isolating variability. The clearer the boundary between core and extensions, the safer and faster it will be to evolve the system.

In the next article, we’ll explore the Liskov Substitution Principle (LSP).

Meanwhile, check out the full repositories with examples in Elixir and Go:

Elixir Example: solid_elixir_examples
Go Example: solid-go-examples

Still have questions? Or maybe you disagree with something? Drop a comment!

Entendendo SOLID de uma vez por todas | Parte 02 - (OCP)

Rafael Honório — Wed, 16 Jul 2025 21:57:11 +0000

Motivação

Fala pessoal tranquilo? esse é o segundo texto da série que estou compartilhando minha experiência de forma direta e “pé-no-chão” sobre SOLID. No primeiro texto eu falei sobre SRP e mostrei como pequenas violações atrapalham a manutenção do código, se caso não viu, da uma passada lá!

Hoje vamos dar um passo adiante com o Open–Closed Principle (OCP), o pilar que nos ensina a estender comportamentos sem modificar o que já está funcionando.

Breve resumo

Esse termo foi cunhado por Bertrand Meyer em 1988 e popularizado por Robert C. Martin (Uncle Bob), o OCP é geralmente resumido na frase:

“Entidades de software devem ser abertas para extensão e fechadas para modificação.”

A ideia parece paradoxal, como algo pode ser aberto para extensões e fechado para modificações? O segredo é uma palavrinha: abstrações (interfaces, behaviours, callbacks).

Conforme os sistemas se tornaram maiores em termos de tamanho dos arquivos, numero de arquivos e relação entre eles, se faz necessário utilizar abstrações para expandir os contextos a ponto de que, não é preciso mexer na implementação raiz para adicionar uma modificação, em outras palavras, "ela nunca muda".

Por exemplo - Uma função que calcula um determinado imposto sobre um produto

O cálculo pode mudar? sim, mas é improvável que mude
Quais são as variáveis? valor do produto + alíquota
Quais são as variáveis que podem mudar? alíquota

São exemplos de perguntas que eu me faço para descobrir o ponto de variação da implementação, nesse caso é improvável que o "como fazer" mude, mas é provável que alíquota mude com o tempo.

Pensando em como normalmente se implementaria um calculo assim:

função fazer_calculo(valor_do_produto), faça:
  valor_do_produto * @aliquota_imposto ou 0.10

O pseudocódigo acima mostra uma implementação simples e direta de como fazer esse processo, porém existe um problema que é, toda vez que o imposto mudar a gente vai precisar modificar essa função e isso pode gerar problemas em outras pontas do software.

Se invês do código acima, fizessemos isso:

função calcular_aliquota(valor_do_produto, calculo_imposto), faça:
  calculo_imposto(valor_do_produto)

Nesse caso não seria necessário modificar essa implementação quando algo mudasse, visto que, estamos passando uma outra função como parâmetro para calcular o novo valor, assim quando adicionarmos novos recursos implementando classes/módulos, não precisamos alterar os contextos já testados no passado, dessa forma expandindo as implementações.

OCP na prática

1. Estratégia de desconto em Go.

Trecho retirado do repositório solid-go-examples:

// interface que define o ponto de variação
type Discount interface {
    Apply(price float64) float64
}

// implementação sem desconto
type NoDiscount struct{}
func (NoDiscount) Apply(price float64) float64 { return 0 }

// implementação com desconto percentual
type PercentageDiscount struct{}
func (PercentageDiscount) Apply(price float64) float64 { return price * 0.1 }

// Função de domínio que não muda quando surgem novos descontos
func CalculatePrice(price float64, d Discount) float64 {
    return price - d.Apply(price)
}

Uso no main.go:

noDisc := NoDiscount{}
percentageDisc := PercentageDiscount{}

fmt.Println(CalculatePrice(100, noDisc)) // 100
fmt.Println(CalculatePrice(100, percentageDisc)) // 90

Por que segue o OCP?

CalculatePrice é fechada para modificação: não precisei tocar nela para incluir PercentageDiscount. Ao mesmo tempo, o sistema está aberto para extensão, pois novos tipos que implementem Discount podem ser criados a qualquer momento (ex: BlackFridayDiscount).

2. Processador de pagamento em Elixir.

Arquivo 02_open_closed_principle.ex do repo solid_elixir_examples:

defmodule PaymentProcessor do
  def process(order, tax_calculator) do
    tax = tax_calculator.(order)
    total = order.amount + tax
    {:ok, %{order: order, tax: tax, total: total}}
  end
end

# diferentes regras fiscais sem alterar o módulo
PaymentProcessor.process(%{amount: 100}, fn o -> o.amount * 0.1 end)
PaymentProcessor.process(%{amount: 100}, fn o -> o.amount * 0.2 end)

Por que segue o OCP?

PaymentProcessor delega o cálculo de imposto para uma função recebida por parâmetro. Quando surge uma nova legislação, criamos outra função (ou módulo) e passamos como argumento, sem tocar na lógica central de processamento.

Dicas para adotar o OCP

Situação de mudança	Abordagem que respeita o OCP
Novos meios de pagamento	Defina uma interface `PaymentGateway` e implemente novos adaptadores sem alterar o que já existe.
Novas regras de tarifação	Use funções de callback ou strategy pattern para encapsular regras isso vai ajudar na manutenibilidade do código e testes.
Novos relatórios	Aplique o pattern Template Method ou gere relatórios via plug-ins em vez de editar a classe base.

Dica de ouro: encontre o ponto de variação do código, provávelmente esse é o ponto que precisa ser encapsulado.

Sinais de violação

switch/case crescendo sempre que aparece um novo tipo de dado.
Testes que quebram em cascata quando apenas um requisito mudou.
Mudança constante no domínio interno (quanto mais mudanças em regras internamente tiver mais se faz necessário aplicar esse conceito).

Conclusão

Aplicar o Open–Closed Principle não é sobre “nunca mais mexer” no código, mas sim sobre minimizar mudanças de alto risco e isolar variabilidade. Quanto mais clara for a fronteira entre núcleo e extensões, mais rápido e seguro será evoluir o sistema.

No próximo artigo vamos explorar o Liskov Substitution Principle (LSP). Enquanto isso, confira os repositórios completos com exemplos em Elixir e Go:

Exemplo em Elixir: solid_elixir_examples
Exemplo em Go: solid-go-examples

Se ainda houver dúvidas ou se você discordar de algo, deixe um comentário!

Entendendo SOLID de uma vez por todas | Parte 01 - (SRP)

Rafael Honório — Sun, 29 Jun 2025 21:57:50 +0000

Motivação

Este é o primeiro texto de uma série onde explicarei, de maneira clara e lúdica, cada um dos conceitos do SOLID. Em vez de replicar conteúdos já disponíveis pela internet, pretendo fazer um dump das minhas experiências pessoais e do meu entendimento sobre o tema. Hoje, iniciaremos com o princípio SRP (Single Responsibility Principle).

Breve resumo

Os conceitos que formam o acrônimo SOLID já são bem conhecidos há pelo menos 20 anos e são frequentemente abordados em entrevistas técnicas. Mais do que isso, entender profundamente cada princípio melhorará significativamente a qualidade do seu código. A intenção destes textos é esclarecer definitivamente cada conceito para que você consiga aplicá-los independentemente da linguagem que utilizar.

Obs.: No final do texto, vou deixar dois repositórios com exemplos práticos implementando cada conceito em Elixir e Golang, contudo, o mais importante é compreender o fundamento para que você consiga adaptá-lo à sua realidade.

SRP - Single Responsibility Principle

Esse termo foi cunhado por Robert Martin (Uncle Bob) em 2000, no livro Design Principles and Design Patterns. Porém, esse é um problema clássico da programação, que surgiu após os anos 80 com o aumento da complexidade das aplicações. Com a complexidade crescendo, tornou-se necessário organizar melhor o código, o que impulsionou a implementação de POO no mercado, visto que já existia pelo menos há 20 anos na década de 80/90.

Segundo o livro Clean Code, o conceito de SRP pode ser resumido da seguinte maneira:

"Uma classe ou módulo deve ter um, e apenas um, motivo para mudar." (Clean Code, pág. 138)

Mas, afinal, o que isso significa? Dentro de uma estrutura, seja ela um módulo, pacote ou classe, qualquer interação que fuja da sua responsabilidade original provavelmente violará o SRP.

Veja estes dois exemplos:

Situação 01: Dentro de uma estrutura de usuário, existem propriedades e métodos que devem sempre refletir ações e características diretamente relacionadas ao usuário. Exemplo:

type User struct {
    Name     string
    Age      int
    Document string
    // outras propriedades
}

// Em Go, este trecho "(u *User)" indica que esta função é um método da struct User.

func (u *User) IsAdult() bool {
    // lógica aqui
}

func (u *User) ValidateDocument(document string) bool {
    // lógica aqui
}

Porém, se adicionarmos algo como:

func (u *User) SaveUser() {
    // lógica aqui
}

Claramente estaremos quebrando o SRP, já que salvar o usuário não deveria ser responsabilidade direta da estrutura de domínio User.

Situação 02: Também é possível violar esse princípio em outras camadas da aplicação. Veja o exemplo abaixo em Elixir:


# Código com violação do SRP

defmodule User do // define o módulo
  def create_user(attrs) do // define a função
    user =
      %User{attrs}
      |> Repo.insert!() // insere no banco de dados
    Email.send_welcome(user) // envia email para o cliente 
    Logger.info("User created: \#{user.id}") // loga a ação
    user // retorna o usuário
  end
end

# Código seguindo o SRP

defmodule UserCreator do
  def create(attrs) do
    Repo.insert!(%UserStruct{attrs})
  end
end

defmodule WelcomeNotifier do
  def send_welcome_email(user) do
    Email.send_welcome(user)
  end
end

Neste exemplo em Elixir, fica claro como é fácil misturar responsabilidades. No código inicial, temos criação de usuário, envio de e-mail e log em uma única função, o que fere o SRP. O código corrigido separa claramente as responsabilidades.

Com esses exemplos, fica mais fácil entender como devemos pensar ao escrever código. Lembre-se de sempre avaliar se cada componente possui apenas uma única razão para mudar, caso haja mais de uma, com certeza o princípio SRP está quebrado nesse contexto.

Repositórios com exemplos práticos:

Se ainda houver dúvidas ou se você discordar de algo, deixe um comentário, até mais!

Understanding SOLID once and for all | Part 01 - (SRP)

Rafael Honório — Sun, 29 Jun 2025 21:57:42 +0000

Motivation

This is the first post in a series where I’ll explain each SOLID concept clearly and engagingly. Instead of repeating content widely available online, I intend to provide a personal dump of my experiences and understanding of these principles. Today, we'll begin with the Single Responsibility Principle (SRP).

Brief Summary

The concepts forming the SOLID acronym have been well-known for at least 20 years and frequently appear in technical interviews. More importantly, deeply understanding these principles significantly improves your code quality. The purpose of these posts is to definitively clarify each concept so you can apply it independently of the programming language you use.

Note: At the end of the post, I’ll include two repositories with practical examples implementing each concept in Elixir and Golang. However, the essential aspect is grasping the underlying principles so you can adapt them to your specific context.

SRP - Single Responsibility Principle

This term was coined by Robert Martin (Uncle Bob) in 2000, in the book Design Principles and Design Patterns. However, this classic programming challenge emerged during the 1980s as application complexity grew significantly. This increased complexity necessitated better code organization, promoting the adoption of Object-Oriented Programming (OOP), which already existed for around two decades by the 80s and 90s.

According to the book Clean Code, the SRP can be summarized as follows:

"A class or module should have one, and only one, reason to change." (Clean Code, p. 138)

But what does that mean in practice? Within a structure, be it a module, package, or class, any interaction that deviates from its original purpose probably violates SRP.

Consider these two examples:

Scenario 01: Within a user structure, properties and methods should always directly reflect user actions and characteristics. For example:

type User struct {
    Name     string
    Age      int
    Document string
    // other properties
}

// In Go, this "(u *User)" indicates the function is a method of the User struct.
func (u *User) IsAdult() bool {
    // logic here
}

func (u *User) ValidateDocument(document string) bool {
    // logic here
}

However, if we add something like:

func (u *User) SaveUser() {
    // logic here
}

We clearly violate SRP, as saving the user should not be the direct responsibility of the domain structure User.

Scenario 02: It's also possible to violate this principle in other application layers. Consider this Elixir example:

# Code violating SRP
defmodule User do
  def create_user(attrs) do
    user =
      %User{attrs}
      |> Repo.insert!()

    Email.send_welcome(user)
    Logger.info("User created: \#{user.id}")
    user
  end
end

# Code adhering to SRP
defmodule UserCreator do
  def create(attrs) do
    Repo.insert!(%UserStruct{attrs})
  end
end

defmodule WelcomeNotifier do
  def send_welcome_email(user) do
    Email.send_welcome(user)
  end
end

This Elixir example clearly illustrates how easy it is to mix responsibilities. The initial code combines user creation, email sending, and logging into one function, violating SRP. The corrected code clearly separates responsibilities.

With these examples, it becomes easier to understand how we should approach writing code. Always evaluate whether each component has only one reason to change—if there's more than one reason, SRP is likely being violated in that context.

If you have any doubts or disagree with anything, feel free to comment!

Repositories with practical examples:

I’ll write about the other principles soon and link them here once published. See you next time!

Is AI Going to Take Our Jobs? A Software Engineer’s Experience with LLMs

Rafael Honório — Wed, 28 May 2025 22:24:40 +0000

Over the past few years, there has been considerable discussion about how AI might replace all our jobs. For a long time, I completely ignored the topic; most of it sounded like pure bu11SH1T. I had already studied neural networks and understood the basics of LLMs, Machine Learning, Deep Learning, Natural Language Processing, and Expert Systems. I had even tested a few generative AI tools, but none of them impressed me; they were buggy, full of hallucinations, and constrained.

Last year (2024), I revisited the subject with more focus. A lot has changed, major improvements were made, but still, nothing close to replacing a real Software Engineer, despite what many headlines suggested at the time.

Since then, I’ve been following the field closely, running experiments and trying to understand how this tech could impact our daily work. That’s how this experiment came to life: I decided to use AI alone to redesign the visual theme of my website (rafaelhs-tech.com). The idea was simple: change only the look and feel of the site. Here’s how it went.

Tech Stack

I originally built my site in 2021 using Angular (version 7 or 8, can’t remember exactly). It was pretty basic, just a few components with a space-themed design.

The Original Version

This was the original version. The journey with AI agents began using Claude 3.7. My first prompt went something like this:

“This is an Angular XX application, and I want to change the style to something with a cyberpunk theme. The folders are organized by components, and each component represents a page.”

Claude scanned the project, found the SASS files, and started generating new code… but then it began to hallucinate: it created React files inside an Angular project.

I tried correcting it, but it kept going off track, breaking the app, mixing files, outputting React code again and again. So, I scrapped everything and started over.

This time, I was more specific: I mentioned the Angular version, outlined the folder structure, highlighted key files, and gave a full project overview. The result? Slightly better visually, but still a broken UI. Misaligned pages, inconsistent styles, and worst of all: the code was a mess.

This kind of output was common. For those unfamiliar, mixing HTML, CSS, and JS like this is bad practice in modern web development.

It wasn’t exactly surprising, but it reinforced a key point: these agents still lack a real understanding of good development practices. I kept using Claude 3.7 for a while, but it got frustrating. I’d ask for one thing, and it would return something completely different. After more than 15 prompts just to align a single button, I realized it would’ve been faster to just fix it manually, but I was committed to simulating a non-technical user experience.

I also tested CodeLLM, but it had another issue: it doesn’t retain long-term memory. If the prompt fails or reaches the token limit, continuing in a new thread resets everything, with no memory of past context. That became really annoying.

Common Hallucinations with Claude 3.7:

Generated things I didn’t ask for
Couldn’t revert changes
Deleted everything and regenerated the code in loops

So I switched to Claude 3.5, which behaved more reliably. It followed instructions with better accuracy. I continued tweaking things and eventually got this result:

The Final Version

After about 40 prompts, I reached a decent visual result. But the code was still messy: CSS mixed with SASS, JS inline with HTML, weird file names, useless comments... nothing reusable. I decided to try other LLMs like Gemini 2.5, GPT o1, and GPT o4mini. The outcome was the same, frustrating, and each run produced noticeably different results (as expected).

Reflections

There’s no doubt AI is changing how we code, learn, and approach problem-solving. But replacing a software engineer? We’re still far from that.

Some notes from this experiment:

I didn’t manually edit any code, even though I knew exactly what to change. That alone made a huge difference.
The project was based on TS, SASS, and HTML, a well-documented and widely used stack, and it still hallucinated a lot. Imagine this with Elixir, Clojure, or Crystal, I’ve tried it. It doesn’t work well.
Code quality was poor. It "worked", but required major rework.
Vague prompts result in vague answers, obvious in theory, but problematic for non-technical users.
The total cost was around $14, mainly from long conversations and resets. If I hadn’t started over several times, it would’ve been around $8 or 9.

Final Thoughts

After all this, I can confidently say: we’re far from singularity. LLMs are, at their core, text input → text output. Sure, there’s complex stuff in the middle, but no actual "intelligence" is happening.

If you repeat the same prompt, results may vary. That’s because LLMs are non-deterministic, they generate responses based on probabilities. Techniques like top-k sampling and top-p sampling can influence the outcome, but randomness is part of the deal.

Yes, this raises the bar for simpler tasks, and that might affect junior devs, but everything depends on context.

Now imagine a real-world complex system with backend logic, BFF, Terraform, CI/CD pipelines, or microservices, where a small UI tweak could have unexpected side effects elsewhere. That’s a mess waiting to happen. I spoke with some friends in mobile development, and their experience was even worse. Honestly, web development might be the "least bad" scenario.

It’s up to us to adapt. I use AI tools every day now, for studying, writing docs, building PRDs, MRDs, diagrams, etc. But we’re still far from AI solving software engineering on its own.

If you enjoyed this reflection, leave a comment and share your own experience using LLMs.

Until next time!

IA vai tirar nossos empregos? A experiência de um engenheiro de software no Frontend com LLMs

Rafael Honório — Wed, 28 May 2025 21:28:08 +0000

Nos últimos anos, muito se tem discutido sobre como a IA pode acabar com nossos empregos. Por um bom tempo, ignorei esse papo, a maior parte parecia puro bu11SH1T. Eu já tinha estudado redes neurais e conhecia o básico sobre LLMs, Machine Learning, Deep Learning, Processamento de Linguagem Natural e Sistemas Especialistas. Já tinha testado algumas ferramentas de IA generativa, mas nada me impressionava: eram bugadas, cheias de "delírios" e bem limitadas.

No ano passado (2024), voltei a estudar o tema com mais atenção. Muita coisa evoluiu, houve avanços relevantes, mas ainda assim, nada que indicasse uma substituição real de um Software Engineer, como várias manchetes sugeriam na época.

Desde então, venho acompanhando de perto, fazendo testes e experimentos, tentando entender melhor como essa tecnologia pode impactar nosso dia a dia. E foi assim que surgiu a ideia deste experimento: utilizar 100% IA para modificar o visual do meu site pessoal (rafaelhs-tech.com). O objetivo era simples: mudar apenas o tema visual do site, vamos ao caso.

Stack

Criei meu site pessoal em 2021 usando Angular (versão 7 ou 8, não lembro ao certo). A estrutura era básica, com a interface separada em componentes e uma pegada visual meio “espaço sideral”.

Como era

Essa era a versão original. A jornada com os agentes de IA começou com o Claude 3.7. Meu primeiro prompt foi algo assim:

“Essa é uma aplicação Angular XX e quero alterar o estilo visual com uma temática cyberpunk. As pastas estão organizadas por componentes, e cada componente representa uma página.”

Claude analisou as páginas, identificou os arquivos SASS, começou a sugerir mudanças... mas aí começou a delirar: criou arquivos em React dentro de um projeto Angular.

Tentei corrigir, mas ele insistia. Sempre surgia algo quebrado, arquivos fora do padrão, ou partes em React. Resultado: joguei tudo fora e recomecei do zero.

Dessa vez, fui mais específico: informei a versão do Angular, a estrutura de pastas, arquivos relevantes, etc. O resultado? Visualmente um pouco melhor, mas o site estava todo quebrado. Páginas desalinhadas, estilizações inconsistentes... e o pior: o código estava uma bagunça.

Esse tipo de resultado era recorrente. Para quem não percebeu: hoje em dia, misturar HTML, CSS e JS desse jeito é má prática em projetos modernos.

Não foi exatamente uma surpresa, mas reforçou uma verdade: esses agentes não têm noção real de boas práticas. Continuei com Claude 3.7 por mais um tempo, mas comecei a me irritar. Pedia uma coisa, ele fazia outra. Foram mais de 15 prompts para alinhar um botão. Chegou um ponto em que seria mais fácil eu mesmo resolver, mas eu queria simular a experiência de um usuário sem conhecimento técnico.

Também testei com o CodeLLM, mas surgiu outro problema: ele não mantém histórico muito longo. A cada nova tentativa, se o prompt quebrava, era necessário recomeçar do zero, sem memória do progresso anterior.

Delírios comuns que enfrentei com Claude 3.7:

Criava coisas que eu não pedi
Não conseguia desfazer alterações
Deletava tudo e começava do zero em loop

Troquei então para o Claude 3.5, e o comportamento foi mais estável. A IA seguiu os comandos com mais precisão. Continuei criando prompts, ajustando o layout e cheguei neste resultado:

Como ficou

Após cerca de 40 prompts, cheguei a um visual legal. Mas o código continuava problemático: mistura de CSS com SASS, JS no meio do HTML, nomes de arquivos esquisitos, comentários inúteis... nada muito aproveitável. Decidi então testar outras LLMs: Gemini 2.5, GPT o1, GPT o4mini. O resultado foi o mesmo: frustração, e me gerou um resultado bem diferente cada tentativa, que era esperado também.

Reflexões

Sem dúvida, a IA está mudando a forma como programamos, estudamos e até pensamos em soluções. Mas substituir um engenheiro de software? Ainda estamos bem longe disso.

Vejo manchetes tratando as LLMs como se fossem o “nirvana do desenvolvimento”, mas, na prática, não é bem assim. Algumas observações:

Em nenhum momento editei o código manualmente, mesmo sabendo como corrigir. Isso faz diferença.
O projeto era em TS, SASS e HTML, um cenário comum e bem documentado. Mesmo assim, a IA cometeu muitos erros. Imagine isso num backend com Elixir, Clojure ou Crystal, não funciona muito bem, eu já tentei.
A qualidade do código gerado é baixa. Funciona, mas exige bastante retrabalho.
Prompts vagos geram respostas vagas, parece óbvio, mas um usuário comum não vai saber ser tão específico.
O custo final ficou em torno de US$ 14. Se eu não tivesse refeito do zero algumas vezes, cairia para uns US$ 8 ou 9.

Conclusão

Depois dessa experiência, posso afirmar: a singularidade está longe. LLMs são, no fim das contas, input de texto → output de texto. Claro, há muito acontecendo entre esses dois pontos, mas não existe “inteligência” real envolvida.

Se você repetir o mesmo prompt, os resultados podem mudar (Não deterministico), as LLMs não escolhem sempre a palavra mais provável é uma base probabilistica, algumas outras ténicas de top-k ou top-p podem mudar o resultado, mas sim, isso eleva a régua para tarefas simples, o que pode impactar profissionais mais iniciantes, mas tudo depende do contexto.

Fico imaginando um cenário com backend, BFF, Terraform, CI/CD... ou mesmo microserviços onde uma mudança gera efeitos colaterais em outros pontos. A chance de virar uma bagunça é alta. Conversei com amigos da área de mobile, e eles confirmaram: lá, a situação é ainda pior, acredito que no contexto web é onde funciona melhor.

Cabe a nós acompanhar essa transição e adaptar nosso workflow. Eu, por exemplo, uso IA todos os dias, para estudar, escrever documentos, criar PRDs, MRDs, diagramas e etc. Mas ainda está longe de resolver muitas questões sozinho.

Se você curtiu essa reflexão, comenta aí e compartilha sua experiência com LLMs.

Do mais, até mais!

RabbitMQ — Primeiros passos (repost de 2018)

Rafael Honório — Tue, 20 May 2025 15:44:25 +0000

Hey oh!

Olá! Quero compartilhar um pouco da minha experiência com o RabbitMQ nos últimos meses. A ideia é criar uma espécie de guia introdutório para quem está começando.

Como a maior parte do conteúdo (inclusive a documentação) está em inglês, resolvi escrever este mini artigo/tutorial para a galera da comunidade que, assim como eu, está melhorando no inglês.

Se você chegou até aqui, provavelmente já sabe o que é um message broker. Mas caso tenha caído de paraquedas, dá uma olhada nesse artigo da Wikipédia e usa o bom e velho Google Tradutor, ele ajuda bastante!

Entre as opções de mercado como Kafka, ActiveMQ, SQS, entre outros, o RabbitMQ é uma excelente escolha. E o melhor: é open source, ao contrário de algumas alternativas citadas. No geral, é uma ferramenta bem completa.

O RabbitMQ tem suporte oficial para várias linguagens: C#, Java, PHP, Python, Ruby, Go, Elixir e por aí vai, as mais utilizadas atualmente.

Neste artigo, divido o conteúdo em três partes:

Cenários de aplicação
Conceitos
Mão na massa

Cenários de aplicação

Gosto de resumir o uso do RabbitMQ em dois cenários comuns:

Quando uma aplicação distribuída precisa se comunicar com várias outras (fanout).
Quando você precisa executar um processo de forma assíncrona, por exemplo: é bem comum em e-commerce dentro do processo de compra, ter várias etapas para finalizar uma compra, carrinho, pagamento, processamento, envio e por ai vai...(topic)


cenário bem comum

A maioria dos casos de uso vai acabar derivando dessas duas situações.

Conceitos

Aqui vão alguns conceitos importantes do RabbitMQ. (Não se preocupe se parecer muita coisa, eu também me perdi nos primeiros dias lendo a documentação.)

A forma mais básica de usar um message broker é: um app envia uma informação para outro app.


Cenário mais simples

Produtor envia uma informação para uma fila (queue) e um consumidor pega essa informação, conceito simples, não é mesmo?


Um pouco mais detalhado

Claro que existem alguns poréns no processo, mas vamos direto ao ponto. Aqui vão os principais conceitos:

Queue: É a fila dentro do servidor RabbitMQ. As filas têm propriedades como exchange, binds, headers e content, que explico a seguir.
Exchange: É o “roteador” das mensagens. Ele decide como e para onde as mensagens serão enviadas. Existem quatro tipos: Direct, Fanout, Topic e Headers.
Bind ou RoutingKey: É o identificador que conecta uma queue a uma exchange. Ele define o caminho que a mensagem vai seguir.

Producer / Publisher: A aplicação que produz e envia a mensagem para o RabbitMQ.
Consumer / Subscriber: A aplicação que consome a mensagem da fila.
Virtual host: O RabbitMQ é multi-tenant, ou seja, permite múltiplos ambientes lógicos. Cada vhost separa conexões, filas, binds, exchanges, policies e usuários. Se você já trabalhou com virtual hosts no Apache ou blocos de servidores no Nginx, a ideia é parecida, mas no RabbitMQ, esses hosts são criados via rabbitmqctl ou pela API.

Com esses conceitos em mente, fica muito mais fácil entender o restante. Tentei manter o texto leve e informal pra facilitar :D

Mão na massa

Agora vamos configurar o servidor e começar a codar!

Vou usar um servidor Linux (Debian) e a linguagem C#, mas o conceito se aplica a qualquer linguagem com suporte a RabbitMQ.

Passo 1 – Instalar o Erlang

Execute os seguintes comandos:

wget https://packages.erlang-solutions.com/erlang-solutions_1.0_all.deb
sudo dpkg -i erlang-solutions_1.0_all.deb
sudo apt-get update
sudo apt-get install erlang erlang-nox

Passo 2 – Instalar o RabbitMQ Server

sudo add-apt-repository 'deb http://www.rabbitmq.com/debian/ testing main'
wget -O- https://www.rabbitmq.com/rabbitmq-release-signing-key.asc | sudo apt-key add -
sudo apt-get update
sudo apt-get install rabbitmq-server

Inicie e habilite o serviço:

sudo systemctl enable rabbitmq-server
sudo systemctl start rabbitmq-server

Pare o servidor (temporariamente):

sudo systemctl stop rabbitmq-server

Criar usuário para o Web Management

sudo rabbitmqctl add_user admin password 
sudo rabbitmqctl set_user_tags admin administrator
sudo rabbitmqctl set_permissions -p / admin ".*" ".*" ".*"

Habilite o plugin de administração:

sudo rabbitmq-plugins enable rabbitmq_management

Inicie o servido novamente:

sudo systemctl start rabbitmq-server

Acesse o painel web em http://localhost:15672
(Usuário: admin / Senha: password)

Liberar portas no firewall (se necessário)

sudo firewall-cmd --add-port=15672/tcp --permanent
sudo firewall-cmd --add-port=5672/tcp --permanent
sudo firewall-cmd --add-port={4369/tcp,25672/tcp} --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

Desta forma o servidor já está configurado, vou mostrar um exemplo criando uma fila e enviando uma informação e consumir em outra app. Existem várias abordagens para trabalhar com rabbitmq, criando uma API http, cronjob, background job e por ai vai.

Passo 3 – Criar uma aplicação para interagir com o RabbitMQ*

Crie uma Console App e adicione a dependência do RabbitMQ client.

dotnet add package RabbitMQ.Client

Crie uma classe para envio de mensagens:

using RabbitMQ.Client;
using System;
using System.Text;

namespace NewTask
{
    class NewTask
    {
        static void Main(string[] args)
        {
            ConnectionFactory factory = new ConnectionFactory()
            {
                HostName = "localhost",
                Port = Protocols.DefaultProtocol.DefaultPort,
                UserName = "admin",
                Password = "admin",
                VirtualHost = "/",
                RequestedHeartbeat = 60
            };

            using (var connection = factory.CreateConnection())
            {
                using (var channel = connection.CreateModel())
                {
                    channel.ExchangeDeclare(
                        exchange: "MediumExchange",
                        type: ExchangeType.Topic,
                        autoDelete: false
                    );

                    channel.QueueDeclare(
                        queue: "queueMediumTeste",
                        durable: true,
                        exclusive: false,
                        autoDelete: false,
                        arguments: null
                    );

                    channel.QueueBind(
                        queue: "queueMediumTeste",
                        exchange: "MediumExchange",
                        routingKey: "MediumBind"
                    );

                    var message = "Olá Medium";
                    var body = Encoding.UTF8.GetBytes(message);

                    var properties = channel.CreateBasicProperties();
                    properties.Persistent = true;

                    channel.BasicPublish(
                        exchange: "MediumExchange",
                        routingKey: "MediumBind",
                        basicProperties: properties,
                        body: body
                    );

                    Console.WriteLine(" [x] Sent {0}", message);
                }
            }

            Console.WriteLine("Press [enter] to exit.");
            Console.ReadLine();
        }
    }
}

Esse código realiza os seguintes passos:

Cria uma Exchange
Cria uma Queue
Cria um Bind
Envia a mensagem (convertida em bytes)
Define se ela deve ser persistida
Publica a mensagem
Mostra no console


a mensagem enviada para o servidor

Agora, crie outro arquivo para consumir a mensagem da fila:

using RabbitMQ.Client;
using RabbitMQ.Client.Events;
using System;
using System.Text;

namespace ConsumerPublishSub
{
    class Program
    {
        static void Main(string[] args)
        {
            ConnectionFactory factory = new ConnectionFactory()
            {
                HostName = "localhost",
                Port = Protocols.DefaultProtocol.DefaultPort,
                UserName = "admin",
                Password = "admin",
                VirtualHost = "/",
                RequestedHeartbeat = 60
            };

            using (IConnection connection = factory.CreateConnection())
            {
                using (IModel channel = connection.CreateModel())
                {
                    Console.WriteLine("Waiting for logs.");

                    var consumer = new EventingBasicConsumer(channel);
                    consumer.Received += (model, ea) =>
                    {
                        var body = ea.Body;
                        var message = Encoding.UTF8.GetString(body.ToArray());
                        Console.WriteLine(" [x] Received {0}", message);
                    };

                    channel.BasicConsume(
                        queue: "QueueMediumTeste",
                        autoAck: true,
                        consumer: consumer
                    );

                    Console.WriteLine(" Press [enter] to exit.");
                    Console.ReadLine();

                    channel.Close();
                }

                connection.Close();
            }
        }
    }
}

A mensagem esperada será:


o resultado esperado

Esse é o básico para começar a usar RabbitMQ com .NET.
No site oficial há um Get Started completo para várias linguagens.

No futuro, quero escrever sobre clusters com RabbitMQ, estou criando uma lib para facilitar essas interações, e em breve compartilho aqui.

Curtiu? Me chama!
Se tiver dúvidas ou quiser trocar ideia:

OBS: esse texto foi escrito em 2018, transferi o artigo para o dev.to por que o medium ficou uma merda, valeu!

Xiaomi RedmiBook: How to Fix Wi-Fi Issues on Linux (Debian distros)

Rafael Honório — Tue, 20 May 2025 12:52:59 +0000

Hey folks 👋

Recently, I bought a Xiaomi RedmiBook 16 to get more mobility and separate my work environment. Everything was going great, until I booted into Linux and realized the Wi-Fi wasn’t working at all.

After some digging, I found out the issue was related to the Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter. It turns out that after installing the OS or updating the kernel, the firmware breaks. Don’t ask me why, but several logs showed the adapter crashing on boot.

If you’re facing the same issue, here’s a simple workaround that worked for me on Ubuntu. It should also help on other Debian-based distros like Kali, Mint, Deepin, Xubuntu and etc.

What’s the problem?

When the kernel loads, the adapter crashes due to incompatible or missing firmware. You’ll likely see something like this in dmesg:

ath10k_pci 0000:01:00.0: failed to fetch board data for bus=pci…
ath10k_pci 0000:01:00.0: failed to load board file…

To fix this, you need to manually replace the firmware files on your system.

If you try searching online, you’ll find several tutorials recommending replacing the main firmware binary. The problem is, most of them point to the same source, and unfortunately, killernetworking.com has been offline for years.

Luckily, I downloaded that binary back then and saved it to a personal drive, since this issue kept happening. I figured it might disappear one day... and it did. So I created a GitHub repository with a .deb package to make things easier.

Step-by-step fix

1 - Clone this repository with this command:

git clone https://github.com/rafael-hs/qualcomm-atheros-qca6174-firmware-adapter

2 - Enter the directory and install the .deb

sudo apt install ./surface-go-wifi_0.0.5_amd64.deb

3 - Then reboot your system:

sudo reboot

That's it! After these steps, your Wi-Fi should be up and running.

Did it work?

It worked perfectly on my Ubuntu install, and I’ve seen others confirm it on similar distros. If you run into any issues or have another solution, drop a comment. It might help someone else!

Thanks for reading and good luck! 🚀