Saga Solid de uma forma divertida(S)

SOLID é um acrônimo que representa cinco princípios essenciais para o design de classes na programação orientada a objetos. Esses princípios nos ajudam a criar código mais organizado, flexível e fácil de manter. Vamos falar deles nessa sequencia:

1. S Princípio da Responsabilidade Única (SRP):
2. O Princípio Aberto/Fechado (OCP):
3. L Princípio da Substituição de Liskov (LSP):
4. I Princípio da Segregação da Interface (ISP):

5. D Princípio da Inversão da Dependência (DIP):

6. Princípio da Responsabilidade Única (SRP):

• Imagine que cada classe é como um super-herói com uma única missão. O SRP diz que uma classe deve ter apenas uma razão para mudar. Em outras palavras, ela deve fazer apenas uma coisa e fazer bem feito. Se você tem uma classe que lida com dados de estudantes, ela não deve se meter em assuntos de bancos de dados ou cálculos matemáticos. Mantenha-a focada!

Exemplo de uso do princípio de responsabilidade única:

Imagine que estamos construindo um sistema de gerenciamento de heróis. Cada herói tem um nome, superpoderes e uma pontuação de popularidade. Vamos criar uma classe Hero que segue o SRP:

`using System;

class Hero
{
    public string Name { get; set; }
    public string[] Superpowers { get; set; }
    public int PopularityScore { get; set; }

    public void IncreasePopularity()
    {
        // Lógica para aumentar a popularidade do herói
        PopularityScore += 10;
        Console.WriteLine($"{Name} ganhou 10 pontos de popularidade!");
    }
}

class Program
{
    static void Main()
    {
        var spiderman = new Hero
        {
            Name = "Homem-Aranha",
            Superpowers = new[] { "Agilidade", "Sentido Aranha", "Lançador de Teias" },
            PopularityScore = 100
        };

        spiderman.IncreasePopularity();
        Console.WriteLine($"Popularidade do {spiderman.Name}: {spiderman.PopularityScore}");
    }
}`

Nesse exemplo, a classe Hero tem apenas uma responsabilidade: representar um herói e gerenciar sua popularidade. Ela não se preocupa com a persistência em banco de dados nem com a exibição na interface do usuário. Isso é delegado a outras partes do sistema.

Agora vou mostrar um exemplo de Violação do SRP, para fixarmos o conceito e nos atentarmos quando estivermos codando...
Recebemos uma demanda para salvar as alterações do Heroi e implementamos na classe HeroManager, que agora faz tudo: cria heróis, salva no banco de dados e exibe na tela. Virou uma bagunça! Veja:

`using System;

class HeroManager
{
    public void CreateHero(string name, string[] superpowers)
    {
        // Lógica para criar um herói
        Console.WriteLine($"Herói {name} criado!");
    }

    public void SaveToDatabase(Hero hero)
    {
        // Lógica para salvar no banco de dados
        Console.WriteLine($"Herói {hero.Name} salvo no banco de dados!");
    }

    public void DisplayHero(Hero hero)
    {
        // Lógica para exibir na tela
        Console.WriteLine($"Nome: {hero.Name}, Superpoderes: {string.Join(", ", hero.Superpowers)}");
    }
}

class Program
{
    static void Main()
    {
        var manager = new HeroManager();
        var ironMan = new Hero { Name = "Homem de Ferro", Superpowers = new[] { "Tecnologia avançada" } };

        manager.CreateHero(ironMan.Name, ironMan.Superpowers);
        manager.SaveToDatabase(ironMan);
        manager.DisplayHero(ironMan);
    }
}`

Nesse exemplo, a classe HeroManager está sobrecarregada. Ela deveria ter apenas a responsabilidade de gerenciar heróis, mas está fazendo muito mais. Isso dificulta a manutenção e torna o código confuso.

Lembre-se sempre do SRP: cada classe deve ter uma única razão para mudar. Mantenha seus heróis (e suas classes) focados em suas missões específicas! 🦸‍♀️🦸‍♂️

Espero que tenham gostado!