“Enquanto a programação estruturada tem como principal foco
as ações (procedimentos e funções), a programação OO se preocupa com os
objetos e seus relacionamentos”.
O que é SOLID?
O que é SOLID?Os princípios SOLID são cinco princípios básicos de programação e design orientados a objetos, introduzidos por Uncle Bob no início de 2000. Robert C. Martin (Uncle
Bob)
PrincípiosSRP – Princípio da Responsabilidade ÚnicaOCP – Princípio Aberto e FechadoLSP – Princípio da Substituição de LiskovISP – Princípio da Segregação de InterfaceDIP – Princípio da Inversão de Dependência
BenefíciosCódigo fácil de se manter, adaptar e se ajustar às alterações de escopo;Código testável e de fácil entendimento;Código extensível para alterações com o menor esforço necessário;Que forneça o máximo de reaproveitamento;
Princípio da Responsabilidade Única
“Uma classe deve ter um, e somente um, motivo para mudar”.
Princípio da Responsabilidade Única
class DebitoContaCorrente{ public function ValidarSaldo($valor) { } public function DebitarConta($valor) { } public function EmitirComprovante() { }}
Princípio da Responsabilidade Única
Essa classe valida o saldo e debita conta e emite comprovante. Ela tende a crescer muito, pois cada vez que houver alguma mudança na forma de validar o saldo, ou
na forma de debitar, ou na forma de emitir comprovante essa classe será alterada.
Agora, aplicando o SRP...
Princípio da Responsabilidade Única
public class DebitoContaCorrente{ public function DebitarConta($valor) { }}public class SaldoContaCorrente{ public function ValidarSaldo($valor) { }}public class ComprovanteContaCorrente{ public function EmitirComprovante() { }}
Princípio da Responsabilidade Única
Agora, as responsabilidades estão separadas e cada classe tem a sua
função.
Princípio do Aberto e Fechado
Entidades de software (classes, módulos, funções, etc) devem estar
abertas para extensão, mas fechadas para modificação.
Princípio do Aberto e Fechado
Princípio do Aberto e Fechado
abstract class CalculadoraSalarioBase{ public function CalcularSalario() ;}class CalculadoraSalarioAnalista extends CalculadoraSalarioBase{ public function CalcularSalario() { return 5000; }}class CalculadoraSalarioArquiteto extends CalculadoraSalarioBase{ public function CalcularSalario() { return 7000; }}
Princípio do Aberto e FechadoSegundo o OCP, a classe base
(CalculadoraSalarioBase) nunca pode mudar (fechada para modificação),
porém a posso tranquilamente estender outras classes a partir
dela(CalculadoraSalarioDiretor, CalculadoraSalarioEstagiario, etc.)
Princípio da substituição de Liskov
Se q(x) é uma propriedade demonstrável dos objetos x de tipo T. Então q(y) deve ser verdadeiro para
objetos y de tipo S onde S é um subtipo de T.
Princípio da substituição de Liskov
Sempre que uma classe cliente esperar uma instância de uma classe
base X, uma instância de uma subclasse Y de X deve poder ser
usada no seu lugar.
Princípio da substituição de Liskov
Um Quadrado é um Retângulo?
Princípio da segregação de interfaces
Muitas interfaces específicas são melhores do que uma interface única.
Princípio da segregação de interfaces
Princípio da segregação de interfacesEssa classe “SuperInterface” fere o ISP, pois
os clientes são obrigados a utilizar uma interface a qual não necessitam. As
implementações desta interface precisarão também suprir as necessidades dos clientes,
implementando métodos que não serão utilizados e/ou não são de sua
responsabilidade.
Princípio da inversão de dependência
Dependa de uma abstração(interfaces) e não de uma implementação(classes concretas).
Princípio da inversão de dependênciapublic class Botao{ private Lampada _lampada; public void Acionar() { if (condicao) _lampada.Ligar(); }}
Princípio da inversão de dependência
Esse exemplo viola o DIP, uma vez que o atributo _lampada receberá
uma classe concreta em vez de uma interface. Sendo que dessa forma o funcionamento do método acionar fica restrito apenas a “Lampada”.
Princípio da inversão de dependênciaO correto é que em vez de usarmos uma classe especifica criarmos uma interface Dispositivo, na qual a classe Lampada a implementará. Assim, o funcionamento
da classe Botao será estendido para todas as classes que implementarem Dispositivo, nos dando flexibilidade.
Princípio da inversão de dependênciapublic class Botao{ private Dispositivo _dispositivo; public void Acionar(){ if (condicao) _dispositivo.Ligar(); }}
public interface Dispositivo{ void Ligar(); void Desligar();}public class Lampada : Dispositivo{ public void Ligar() {
// ligar lampada } public void Desligar(){ //desligar lampada }}
Princípio da inversão de dependência
“Classes devem ter alta coesão e baixo acoplamento.”
“Programe voltado a interface e não à implementação.”
“Evite herança, prefira composição.”
http://www.infoq.com/br/presentations/principios-solidhttp://eduardopires.net.br/2013/04/orientacao-a-objeto-solid/
https://brizeno.wordpress.com/2012/01/15/principios-de-design-de-software-interface-segregation-principle/
http://www.macoratti.net/11/05/pa_solid.htm
Bibliografia
Recommended