Forem: Clóvis Chakrian

🚀 SOLID: The Practical Guide to Maintainable Code

Clóvis Chakrian — Tue, 18 Mar 2025 16:06:08 +0000

If you've ever worked on a project that started off simple but quickly became a maintenance nightmare, you’ve likely dealt with rigid, tightly coupled, and hard-to-scale code.

The SOLID principles exist to prevent exactly that. They help you write code that’s more organized, flexible, and easier to maintain. Let’s go through them with clear explanations and practical examples!

📌 S - Single Responsibility Principle (SRP)

"A class should have only one reason to change."

Imagine a class that does everything: processes orders, generates invoices, and sends emails.

public class OrderService
{
    public void ProcessOrder() { /* logic */ }
    public void GenerateInvoice() { /* logic */ }
    public void SendEmail() { /* logic */ }
}

❌ The problem? Any change in the invoice logic could unintentionally impact email sending.

✅ Solution: Separate responsibilities:

public class OrderProcessor { /* Processes the order */ }
public class InvoiceService { /* Generates invoices */ }
public class EmailService { /* Sends emails */ }

Now, each class has a single responsibility, making maintenance much easier.

📌 O - Open/Closed Principle (OCP)

"Code should be open for extension but closed for modification."

Imagine a system that calculates discounts for different customers:

public class Order
{
    public decimal CalculateDiscount(string customerType)
    {
        if (customerType == "Premium") return 0.2m;
        if (customerType == "Regular") return 0.1m;
        return 0m;
    }
}

❌ The problem? Adding a new customer type requires modifying this class, breaking OCP.

✅ Solution: Use an extensible structure:

public interface IDiscount { decimal Apply(); }

public class PremiumDiscount : IDiscount { public decimal Apply() => 0.2m; }
public class RegularDiscount : IDiscount { public decimal Apply() => 0.1m; }

public class Order
{
    private readonly IDiscount _discount;
    public Order(IDiscount discount) { _discount = discount; }
    public decimal CalculateDiscount() => _discount.Apply();
}

Now, we can add new discount types without modifying existing code.

📌 L - Liskov Substitution Principle (LSP)

"Subclass objects should be replaceable with superclass objects without breaking the code."

Let’s say we have a Bird class defining common behaviors:

public class Bird
{
    public virtual void Fly()
    {
        Console.WriteLine("The bird is flying!");
    }
}

Now, we want to add a penguin, but it can’t fly! If we override Fly() in a Penguin subclass, we get an issue:

public class Penguin : Bird
{
    public override void Fly()
    {
        throw new NotImplementedException("Penguins don't fly!");
    }
}

❌ The problem? If a function expects a Bird but gets a Penguin, calling Fly() could crash the application.

✅ Solution: Restructure the hierarchy:

public abstract class Bird { }

public interface IFlyable
{
    void Fly();
}

public class Swallow : Bird, IFlyable
{
    public void Fly() => Console.WriteLine("The swallow is flying!");
}

public class Penguin : Bird
{
    public void Swim() => Console.WriteLine("The penguin is swimming!");
}

Now, only birds that actually fly implement IFlyable, ensuring correct behavior.

📌 I - Interface Segregation Principle (ISP)

"A class should not be forced to implement methods it doesn’t use."

Suppose we have an interface IEmployeeActions that forces all classes to implement unnecessary methods:

public interface IEmployeeActions
{
    void Work();
    void Manage();
}

public class Developer : IEmployeeActions
{
    public void Work() { /* logic */ }
    public void Manage() { throw new NotImplementedException(); }
}

❌ The problem? A developer doesn’t manage, yet it’s forced to implement Manage().

✅ Solution: Create smaller, more specific interfaces:

public interface IWork { void Work(); }
public interface IManage { void Manage(); }

public class Developer : IWork
{
    public void Work() { /* logic */ }
}

Now, each class implements only what it actually needs.

📌 D - Dependency Inversion Principle (DIP)

"High-level modules should not depend on low-level modules. Both should depend on abstractions."

Suppose an order service directly depends on a payment service:

public class OrderService
{
    private readonly PaymentService _paymentService = new PaymentService();

    public void ProcessOrder() { _paymentService.ProcessPayment(); }
}

❌ The problem? If PaymentService changes, OrderService might break.

✅ Solution: Use dependency injection and abstractions:

public interface IPaymentService { void ProcessPayment(); }

public class OrderService
{
    private readonly IPaymentService _paymentService;

    public OrderService(IPaymentService paymentService)
    {
        _paymentService = paymentService;
    }

    public void ProcessOrder() { _paymentService.ProcessPayment(); }
}

Now, we can swap payment service implementations without modifying OrderService.

🎯 Conclusion

SOLID principles aren’t just theoretical—they help create flexible and maintainable code. But remember: not everything needs to be over-abstracted. The key is to apply SOLID wisely, keeping code clean without overcomplicating it.

And you? Have you ever dealt with a project that completely ignored SOLID? Share your experience in the comments! 🚀

🚀 SOLID: O Guia Prático para Código Manutenível

Clóvis Chakrian — Tue, 18 Mar 2025 16:04:45 +0000

Se você já trabalhou em projetos que pareciam fáceis no começo, mas com o tempo viraram um pesadelo de manutenção, provavelmente sofreu com código rígido, acoplado e difícil de escalar.

Os princípios SOLID surgiram exatamente para evitar esse problema. Eles ajudam a escrever um código mais organizado, flexível e fácil de manter. Vamos ver, de forma objetiva e com exemplos práticos, como aplicá-los no dia a dia!

📌 S - Single Responsibility Principle (SRP)

"Uma classe deve ter apenas uma razão para mudar."

Imagine uma classe que faz tudo: processa pedidos, gera nota fiscal e envia e-mails.

public class PedidoService
{
    public void ProcessarPedido() { /* lógica */ }
    public void GerarNotaFiscal() { /* lógica */ }
    public void EnviarEmail() { /* lógica */ }
}

❌ O problema? Sempre que precisar mudar a nota fiscal, pode acabar impactando o envio de e-mails.

✅ Solução: Separar responsabilidades:

public class PedidoProcessor { /* Processa o pedido */ }
public class NotaFiscalService { /* Gera nota fiscal */ }
public class EmailService { /* Envia e-mails */ }

Agora, cada classe tem apenas uma responsabilidade, facilitando a manutenção.

📌 O - Open/Closed Principle (OCP)

"O código deve estar aberto para extensão, mas fechado para modificação."

Imagine um sistema que calcula descontos para diferentes clientes:

public class Pedido
{
    public decimal CalcularDesconto(string tipoCliente)
    {
        if (tipoCliente == "Premium") return 0.2m;
        if (tipoCliente == "Regular") return 0.1m;
        return 0m;
    }
}

❌ O problema? Se surgir um novo tipo de cliente, precisamos modificar essa classe, quebrando o OCP.

✅ Solução: Criar uma estrutura extensível:

public interface IDesconto { decimal Aplicar(); }

public class DescontoPremium : IDesconto { public decimal Aplicar() => 0.2m; }
public class DescontoRegular : IDesconto { public decimal Aplicar() => 0.1m; }

public class Pedido
{
    private readonly IDesconto _desconto;
    public Pedido(IDesconto desconto) { _desconto = desconto; }
    public decimal CalcularDesconto() => _desconto.Aplicar();
}

Agora, podemos adicionar novos descontos sem mexer no código existente.

📌 L - Liskov Substitution Principle (LSP)

"Objetos de uma subclasse devem poder substituir objetos da superclasse sem quebrar o código."

Imagine que temos uma classe Ave que define um comportamento comum para todas as aves:

public class Ave
{
    public virtual void Voar()
    {
        Console.WriteLine("A ave está voando!");
    }
}

Agora, queremos adicionar um pinguim ao nosso código, mas ele não pode voar! Se criarmos uma subclasse Pinguim e sobrescrevermos Voar(), teremos um problema:

public class Pinguim : Ave
{
    public override void Voar()
    {
        throw new NotImplementedException("Pinguins não voam!");
    }
}

❌ O problema? Se um código espera receber uma Ave, mas recebe um Pinguim, pode acabar chamando Voar() e quebrando a aplicação.

✅ Solução: Precisamos reorganizar a hierarquia e evitar forçar um comportamento que nem todas as subclasses podem ter.

public abstract class Ave { }

public interface IVoavel
{
    void Voar();
}

public class Andorinha : Ave, IVoavel
{
    public void Voar() => Console.WriteLine("A andorinha está voando!");
}

public class Pinguim : Ave
{
    public void Nadar() => Console.WriteLine("O pinguim está nadando!");
}

Agora, garantimos que somente as aves que realmente voam implementem IVoavel, e evitamos problemas de substituição.

📌 I - Interface Segregation Principle (ISP)

"Uma interface não deve forçar uma classe a implementar métodos que ela não usa."

Suponha que temos uma interface IAcaoFuncionario que obriga todas as classes a implementarem métodos desnecessários:

public interface IAcaoFuncionario
{
    void Trabalhar();
    void Gerenciar();
}

public class Desenvolvedor : IAcaoFuncionario
{
    public void Trabalhar() { /* lógica */ }
    public void Gerenciar() { throw new NotImplementedException(); }

❌ O problema? Um desenvolvedor não gerencia, mas é obrigado a implementar o método.

✅ Solução: Criar interfaces menores e específicas:

public interface ITrabalho { void Trabalhar(); }
public interface IGerencia { void Gerenciar(); }

public class Desenvolvedor : ITrabalho
{
    public void Trabalhar() { /* lógica */ }
}

Agora, cada classe implementa apenas o que precisa.

📌 D - Dependency Inversion Principle (DIP)

"Módulos de alto nível não devem depender de módulos de baixo nível, mas sim de abstrações."

Suponha que um serviço de pedidos dependa diretamente de um serviço de pagamento:

public class PedidoService
{
    private readonly PagamentoService _pagamentoService = new PagamentoService();

    public void ProcessarPedido() { _pagamentoService.RealizarPagamento(); }
}

❌ O problema? Se PagamentoService mudar, PedidoService pode quebrar.

✅ Solução: Usar injeção de dependência e abstrações:

public interface IPagamentoService { void RealizarPagamento(); }

public class PedidoService
{
    private readonly IPagamentoService _pagamentoService;

    public PedidoService(IPagamentoService pagamentoService)
    {
        _pagamentoService = pagamentoService;
    }

    public void ProcessarPedido() { _pagamentoService.RealizarPagamento(); }
}

Agora, podemos trocar a implementação de pagamento sem alterar PedidoService.

🎯 Conclusão

Os princípios SOLID não são apenas teoria — eles ajudam a criar código mais flexível e de fácil manutenção. Mas lembre-se: nem tudo precisa ser superabstraído. O segredo é aplicar SOLID com equilíbrio, garantindo um código limpo sem exageros.

E você, já enfrentou código que ignorava SOLID? Comenta aqui sua experiência! 🚀

🚀 Object-Oriented Programming (OOP): The Game Changer for Developers!

Clóvis Chakrian — Sun, 16 Mar 2025 14:26:34 +0000

Have you ever heard of OOP and thought, "Oh no, another boring theoretical concept"? Hold on! Understanding Object-Oriented Programming can be a game changer in any developer's career.

Whether you're a beginner stepping into the world of programming or a professional looking to write cleaner and more reusable code, OOP is one of those skills that truly make a difference in the job market. And it's no exaggeration to say that most modern software— from CRMs to banking apps— is built on these principles.

Today, we’ll break down OOP in a simple and practical way— no fluff, just straight to the point. Let’s go!

🧩 What is Object-Oriented Programming?

OOP is a programming paradigm that organizes code in a structured and modular way, bringing it closer to the real world. Instead of scattered functions and variables, we work with objects, which represent real-world entities with their own characteristics and behaviors.

Imagine you're developing a system for a restaurant. You could create an object called "Order", which has attributes like items, customer, and total price, along with behaviors such as adding an item, calculating the total, and closing the order.

Instead of handling multiple loose variables, you group everything that makes sense into a single object. This brings better organization, reusability, and scalability to your code.

🏗 The 4 Pillars of OOP

OOP is based on four fundamental concepts, which are at the heart of this paradigm. Let’s break them down with examples in .NET:

1️⃣ Encapsulation: Protecting Data

Encapsulation means hiding the internal details of an object and allowing access only through specific methods. This prevents external parts of the code from modifying data improperly.

In .NET, we use access modifiers like private and public to control this.

📌 Example:

public class BankAccount
{
    private decimal balance; // Protecting the balance

    public void Deposit(decimal amount)
    {
        balance += amount;
    }

    public decimal GetBalance()
    {
        return balance;
    }
}

2️⃣ Inheritance: Reusing Code

Inheritance allows a class to inherit characteristics and behaviors from another, avoiding code duplication.

📌 Example:

public class Vehicle
{
    public string Model { get; set; }
    public void Accelerate() => Console.WriteLine("Accelerating...");
}

public class Car : Vehicle
{
    public int NumberOfDoors { get; set; }
}

Now, any Car we create will automatically have the properties of a Vehicle. This avoids rewriting repetitive code.

3️⃣ Polymorphism: Flexibility in Code

Polymorphism allows the same method to be implemented in different ways across different classes.

📌 Example:

public class Animal
{
    public virtual void MakeSound()
    {
        Console.WriteLine("Generic animal sound");
    }
}

public class Dog : Animal
{
    public override void MakeSound()
    {
        Console.WriteLine("Woof woof!");
    }
}

This allows the MakeSound() method to be interpreted differently depending on the context, making the code more flexible.

4️⃣ Abstraction: Focusing on What Matters

Abstraction allows us to create more generic structures, hiding unnecessary details and focusing only on what’s essential.

📌 Example:

public abstract class Payment
{
    public abstract void ProcessPayment();
}

public class CardPayment : Payment
{
    public override void ProcessPayment()
    {
        Console.WriteLine("Payment processed via card.");
    }
}

In this example, we have an abstract class Payment, which defines a method ProcessPayment(), but each type of payment can implement it differently.

🚀 Why Is OOP Essential in the Job Market?

If you’re planning to work in software development, mastering OOP is a must. Here’s why:

✅ Better organization and maintainability: Cleaner and well-structured code.

✅ Code reusability: With inheritance and polymorphism, we avoid repetition.

✅ Scalability: Large systems need modular code.

✅ Easier testing: Encapsulated methods are easier to test.

Major frameworks like ASP.NET Core, Spring Boot, and Django are heavily based on OOP. If you want to grow in your career, understanding this paradigm is essential.

🎯 Conclusion

Object-Oriented Programming is not just an academic concept— it’s a powerful way to organize and structure modern applications. Through its four pillars— Encapsulation, Inheritance, Polymorphism, and Abstraction— we can create cleaner, more reusable, and flexible code.

If you haven’t mastered OOP yet, why not start today? Practice, write code, and explore the frameworks that use this paradigm. 🚀

What do you think about OOP? Do you use it in your daily work? Drop a comment, and let’s discuss!

Programação Orientada a Objetos (POO): O que é e por que você precisa dominar isso?

Clóvis Chakrian — Sun, 16 Mar 2025 14:19:46 +0000

Se você já ouviu falar de POO e ficou com aquela cara de "mais um conceito teórico chato", segura aí! Porque entender Programação Orientada a Objetos é um divisor de águas na vida de qualquer desenvolvedor.

Seja você um iniciante querendo entrar no mundo da programação ou um profissional buscando escrever códigos mais organizados e reutilizáveis, POO é uma daquelas habilidades que fazem a diferença no mercado. E não é exagero dizer que a maioria dos softwares modernos — de CRMs a aplicativos bancários — são construídos com base nesses princípios.

Hoje, vamos desvendar a POO de forma simples, com exemplos práticos e, claro, sem enrolação. Bora lá?

🧩 O que é Programação Orientada a Objetos?

POO é um paradigma de programação que organiza o código de forma estruturada e modular, aproximando-o do mundo real. Em vez de apenas funções soltas e variáveis espalhadas pelo código, trabalhamos com objetos, que representam entidades do mundo real com características e comportamentos próprios.

Imagine que você está desenvolvendo um sistema para um restaurante. Você poderia criar um objeto chamado "Pedido", que tem atributos como pratos, cliente e preço total, além de comportamentos como adicionar item ao pedido, calcular total e fechar pedido.

Ou seja, em vez de ter um monte de variáveis soltas, você agrupa tudo que faz sentido dentro de um único objeto. Isso traz mais organização, reutilização e escalabilidade ao código.

🏗 Os 4 pilares da POO

A POO se baseia em quatro conceitos fundamentais, que são o coração desse paradigma. Vamos entender cada um deles com exemplos no .NET:

1️⃣ Encapsulamento: Protegendo os dados

Encapsulamento significa esconder os detalhes internos de um objeto e permitir o acesso apenas através de métodos específicos. Isso evita que partes externas do código alterem os dados de forma indevida.

No .NET, usamos modificadores de acesso como private e public para controlar isso.

📌 Exemplo prático:

public class ContaBancaria
{
    private decimal saldo; // Protegendo o saldo

    public void Depositar(decimal valor)
    {
        saldo += valor;
    }

    public decimal ObterSaldo()
    {
        return saldo;
    }
}

2️⃣ Herança: Reutilizando código

Herança permite que uma classe herde características e comportamentos de outra, evitando duplicação de código.

📌 Exemplo prático:

public class Veiculo
{
    public string Modelo { get; set; }
    public void Acelerar() => Console.WriteLine("Acelerando...");
}

public class Carro : Veiculo
{
    public int NumeroDePortas { get; set; }
}

Agora, qualquer carro que criarmos automaticamente terá as características de um veículo. Isso evita que precisemos reescrever código repetitivo.

3️⃣ Polimorfismo: Flexibilidade no código

Polimorfismo permite que um mesmo método seja implementado de diferentes formas em classes distintas.

📌 Exemplo prático:

public class Animal
{
    public virtual void FazerSom()
    {
        Console.WriteLine("Som genérico de animal");
    }
}

public class Cachorro : Animal
{
    public override void FazerSom()
    {
        Console.WriteLine("Au au!");
    }
}

Isso permite que o método FazerSom() seja interpretado de forma diferente dependendo do contexto, tornando o código mais flexível.

4️⃣ Abstração: Focando no essencial

A abstração nos permite criar estruturas mais genéricas, ocultando detalhes desnecessários e focando apenas no que é relevante.

📌 Exemplo prático:

public abstract class Pagamento
{
    public abstract void ProcessarPagamento();
}

public class PagamentoCartao : Pagamento
{
    public override void ProcessarPagamento()
    {
        Console.WriteLine("Pagamento processado via cartão.");
    }
}

Nesse exemplo, temos uma classe Pagamento abstrata, que define um método ProcessarPagamento(), mas cada tipo de pagamento pode implementar de maneira diferente.

🚀 Por que POO é essencial no mercado de trabalho?

Se você pretende trabalhar com desenvolvimento de software, dominar POO é obrigatório. Aqui estão algumas razões:

✅ Organização e manutenção: Código mais limpo e estruturado.

✅ Reutilização de código: Com herança e polimorfismo, evitamos repetição.

✅ Escalabilidade: Sistemas grandes precisam de código modular.

✅ Facilidade de testes: Métodos encapsulados são mais fáceis de testar.

Grandes frameworks como ASP.NET Core, Spring Boot e Django são fortemente baseados em POO. Se você quer evoluir na carreira, entender esse paradigma é essencial.

🎯 Conclusão

Programação Orientada a Objetos não é apenas um conceito acadêmico, mas sim uma forma poderosa de organizar e estruturar aplicações modernas. Através de seus pilares – Encapsulamento, Herança, Polimorfismo e Abstração – conseguimos criar código mais limpo, reutilizável e flexível.

Se você ainda não domina POO, que tal começar hoje mesmo? Pratique, escreva código e explore os frameworks que utilizam esse paradigma. 🚀

E aí, o que você acha da POO? Já usa no seu dia a dia? Comenta aqui e vamos trocar ideias!