lecture-solid-design

Instituto Federal do Rio Grande do Norte — Campus Parnamirim

Além da Sintaxe: Construindo Aplicações Robustas

SOLID: A Arte do Design de Software

Curso: Superior de Tecnologia em Sistemas para Internet
Prof. Daniel Aguiar | daniel.aguiar@ifrn.edu.br
github.com/daguiardev

---

Agenda da Aula

⚠️

1. Problema

O caos do código acoplado.

⏳

2. Origem

História e conceitos.

💻

3. Os 5 Pilares

Análise prática do SOLID.

📊

4. ROI & Fim

Retorno e revisão.

---

⚠️ O Sintoma: Código “Colcha de Retalhos”

"Mudamos o formato do e-mail de notificação e as consultas ao banco de dados pararam de funcionar."

À medida que o sistema cresce, pequenas alterações geram um efeito cascata imprevisível. O software perde flexibilidade e a equipe ganha medo de refatorar.

Rigidez: Difícil de mudar.

Fragilidade: Quebra em locais aleatórios.

Imobilidade: Impossível reaproveitar.

Viscosidade: Gambiarras são mais fáceis.

---

De onde surgiu o SOLID?

• Robert C. Martin (“Uncle Bob”): Compilou os princípios no início dos anos 2000.
• Michael Feathers: Popularizou o acrônimo.
• Foco Central: Mitigar problemas de design na Programação Orientada a Objetos (POO).

Objetivos Primordiais

• Manutenibilidade: Facilitar correções e evolução do sistema.
• Escalabilidade: Permitir crescimento seguro do projeto.

---

O Acrônimo Desmistificado

S

Single Responsibility
Uma única responsabilidade.

O

Open / Closed
Aberto a extensões, fechado a alterações.

L

Liskov Substitution
Subclasses seguras.

I

Interface Segregation
Interfaces enxutas.

D

Dependency Inversion
Dependa de abstrações.

---

S — Single Responsibility Principle (SRP)

” Uma classe deve ter um, e apenas um, motivo para mudar.”

// Responsabilidades devidamente isoladas
class Pedido {
  private items: string[] = [];
  calcularTotal() { return this.items.length * 10; }
}

class PedidoRepository {
  salvar(pedido: Pedido) { /* conexão banco */ }
}

class NotificationService {
  enviarEmail(msg: string) { /* disparo e-mail */ }
}

---

O — Open/Closed Principle (OCP)

“Entidades devem estar abertas para extensão, mas fechadas para modificação.”

interface Frete { calcular(peso: number): number; }

class FretePAC implements Frete { calcular(p: number) { return p * 5; } }
class FreteSedex implements Frete { calcular(p: number) { return p * 15; } }

class CalculadoraFrete {
  calcular(frete: Frete, peso: number) { return frete.calcular(peso); }
}

---

L — Liskov Substitution Principle (LSP)

“Classes derivadas devem poder ser substituídas por suas classes base.”

class Ave { comer() { return "comendo"; } }

class AveQueVoa extends Ave { voar() { return "voando"; } }

class Pinguim extends Ave {
  // Pinguim não herda voar() incorretamente. Evita bugs inesperados.
  nadar() { return "nadando"; }
}

---

I — Interface Segregation Principle (ISP)

“Uma classe não deve ser forçada a depender de interfaces que não utiliza.”

interface Trabalhavel { trabalhar(): void; }
interface Comivel { comer(): void; }

class Humano implements Trabalhavel, Comivel {
  trabalhar() {}
  comer() {}
}

class Robo implements Trabalhavel {
  trabalhar() {} // Não é forçado a implementar "comer()"
}

---

D — Dependency Inversion Principle (DIP)

“Dependa de abstrações, não de implementações.”

interface Database { connect(): void; }

class MySQLConnection implements Database { connect() { /* ... */ } }

class SistemaPrincipal {
  // O sistema depende do contrato (Interface), não do driver rígido do banco
  constructor(private db: Database) {}
}

---

O Retorno do Investimento (ROI) do SOLID

• Flexibilidade: O design SOLID dita como seu software reage a mudanças.
• Maturidade Prática: Evite over-engineering; aplique conforme a necessidade.
• Padrão de Mercado: Clean Architecture e DDD fundamentam-se nesses pilares.

---

Obrigado!

“Escrever código limpo é um ato de respeito pelo próximo desenvolvedor.”
✉️ daniel.aguiar@ifrn.edu.br
💻 github.com/daguiardev

---

This site is open source. Improve this page.