Solid RELAÇÃO COM GOF
O objetivo desse documento é mostrar que o design SOLID possui 5 princípios relacionados com os criacionais do GOF(GANG OF FOUR).
Assim que um princípio mostra e faz, o GOF é a implementação desse design.
Assim que um princípio mostra e faz, o GOF é a implementação desse design.
Parte 2: SOLID (EXPLICAÇÂO)
S - Single Responsibility Principle (SRP)
Uma classe deve ter um único motivo para mudar:
✔ Separou responsabilidade: gerar ≠ imprimir
O - Open/Closed Principle (OCP)
Aberto para extensão, fechado para modificação:
✔ Você adiciona novos descontos sem mexer no código existente.
L - Liskov Substitution Principle (LSP)
Subclasses devem poder substituir a classe base:
✔ Aqui está errado → quebra o princípio
I - Interface Segregation Principle (ISP)
Interfaces pequenas e específicas:
✔ Evita obrigar classes a implementar o que não usam
D - Dependency Inversion Principle (DIP)
Dependa de abstrações, não de implementações:
✔ Classe depende da interface, não do Email direto.
REFERÊNCIA: https://www.youtube.com/watch?v=-vnEq9IdIJQ&pp=ygUJc29saWQgcGhw
Uma classe deve ter um único motivo para mudar:
class Relatorio {
public String gerar() {
return "dados do relatório";
}
}
class Impressora {
public void imprimir(String conteudo) {
System.out.println(conteudo);
}
}
✔ Separou responsabilidade: gerar ≠ imprimir
O - Open/Closed Principle (OCP)
Aberto para extensão, fechado para modificação:
interface Desconto {
double aplicar(double valor);
}
class DescontoNatal implements Desconto {
public double aplicar(double valor) {
return valor * 0.9;
}
}
✔ Você adiciona novos descontos sem mexer no código existente.
L - Liskov Substitution Principle (LSP)
Subclasses devem poder substituir a classe base:
class Ave {
public void voar() {}
};
class Pardal extends Ave {}
class Pinguim extends Ave {
// problema: pinguim não voa;
}✔ Aqui está errado → quebra o princípio
I - Interface Segregation Principle (ISP)
Interfaces pequenas e específicas:
interface Trabalhador {
void trabalhar();
}
interface Comedor {
void comer();
}
✔ Evita obrigar classes a implementar o que não usam
D - Dependency Inversion Principle (DIP)
Dependa de abstrações, não de implementações:
interface Notificacao {
void enviar(String msg);
}
class Email implements Notificacao {
public void enviar(String msg) {
System.out.println("Email: " + msg);
}
}
class Servico {
private Notificacao notificacao;
public Servico(Notificacao notificacao) {
this.notificacao = notificacao;
}
}
✔ Classe depende da interface, não do Email direto.
REFERÊNCIA: https://www.youtube.com/watch?v=-vnEq9IdIJQ&pp=ygUJc29saWQgcGhw