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:
S Princípio da Responsabilidade Única (SRP):
O Princípio Aberto/Fechado (OCP):
L Princípio da Substituição de Liskov (LSP):
I Princípio da Segregação da Interface (ISP):
D Princípio da Inversão da Dependência (DIP):
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; }
{
// 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
};
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!”);
}
{
// 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.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!
