S.O.L.I.D.

Princpios da programao COTI Informtica

Orientada a Objetos Escola de Nerds

Introduo ao SOLID
Os princpios SOLID devem ser aplicados no desenvolvimento de software de forma que o software
produzido tenha as seguintes caractersticas:

Seja fcil de manter, adaptar e se ajustar s constantes mudanas exigidas pelos clientes;
Seja fcil de entender e testar;
Seja construdo de forma a estar preparado para ser facilmente alterado com o menor esforo
possvel;
Seja possvel de ser reaproveitado;
Exista em produo o maior tempo possvel;
Que atenda realmente as necessidades dos clientes para o qual foi criado;
Introduo ao SOLID
Os princpios SOLID para programao e design orientados a objeto so de autoria de Robert C.
Martin (mais conhecido como Uncle Bob) e datam do incio de 2000. A palavra SOLID um
acrstico onde cada letra significa a sigla de um princpio, so eles: SRP, OCP, LSP, ISP e DIP

Uma classe deve ter um, e somente um, motivo para

The Single Responsibility Principle
SRP
Principio da Responsabilidade nica
The Open Closed Principle
OCP
Princpio Aberto-Fechado
The Liskov Substitution Principle
LSP
Princpio da Substituio de Liskov
The Interface Segregation Principle
ISP
Princpio da Segregao da Interface
The Dependency Inversion Principle
DIP
Princpio da inverso da dependncia
mudar.
A class should have one, and only one, reason to
change.
Voc deve ser capaz de estender um comportamento
de uma classe, sem modific-lo.
You should be able to extend a classes behavior,
without modifying it.
As classes derivadas devem poder substituir suas
classes bases.
Derived classes must be substitutable for their base
classes.
Muitas interfaces especficas so melhores do que
uma interface geral
Make fine grained interfaces that are client specific.
Dependa de uma abstrao e no de uma
implementao.
Depend on abstractions, not on concretions.
Introduo ao SOLID
Letra Sigla Nome Definio
Principio da Uma classe deve ter um, e somente um,
S SRP
Responsabilidade nica motivo para mudar.

Voc deve ser capaz de estender um

Princpio Aberto-
O OCP comportamento de uma classe, sem
Fechado modific-lo.

Princpio da Substituio As classes derivadas devem ser

L LSP
de Liskov substituveis por suas classes base.

Princpio da Segregao Muitas interfaces especficas so

I ISP
da Interface melhores do que uma interface nica.

Princpio da inverso da Dependa de uma abstrao e no de

D DIP
dependncia uma implementao.
Princpio da
Responsabilidade
COTI Informtica
nica Escola de Nerds
1) Princpio da Responsabilidade nica
1) Princpio da Responsabilidade nica

Uma classe s deveria ter um

nico motivo para mudar.
A Audicia
Determinar a nica responsabilidade de uma classe ou mdulo, muito mais complexo
que, simplesmente, verificar em uma lista pr-determinada. Por exemplo, uma dica para
encontrarmos as razes para mudanas verificar o audincia da nossa classe. Os
usurios da aplicao ou sistema que desenvolvemos que requisitaro mudanas para
ela. Aqueles que usam que pediro mudanas. Eis alguns mdulos e suas possveis
audincias.

Mdulo de Persistncia - Pode incluir os DBAs e arquitetos de software;

Mdulo de Relatrio - Pode incluir os contadores, secretrios e administradores;
Mdulo de Computao de Pagamento para um Sistema de Pagamento - Pode incluir os
advogados, administradores e contadores;
Mdulo de Busca de Livros para um Sistema de Administrao de Biblioteca - Pode
incluir os bibliotecrios e/ou os prprios clientes.
1) Princpio da Responsabilidade nica

Uma responsabilidade um conjunto de

funes que serve a um ator em particular.
(Robert C. Martin)
Atores e Papis
Associar pessoas reais a todas os papis existentes pode ser difcil. Em uma pequena
empresa, uma nica pessoa pode ter de satisfazer vrios papis, enquanto em uma
empresa maior, pode ter vrias pessoas alocadas para um mesmo papel. Assim, faz
bastante sentido pensar sobre esses papis. Mas os papis, em si, so um pouco difceis
de definir. O que um papel? Como os encontramos? muito mais fcil pensar em
pessoas realizando determinados papis e associa-los nossa audincia.

Assim, se nossa audincia define os motivos para as mudanas, os atores definem a

audincia. Isso nos ajuda a reduzir os conceitos de pessoas como "John o arquiteto" em
Arquitetura, ou "Maria a administradora" em Administrao.
1) Princpio da Responsabilidade nica

O ator de uma responsabilidade

a nica fonte de mudana para
aquela responsabilidade.
(Robert C. Martin)
Fonte da Mudana
Seguindo esse raciocnio, os atores tornam-se a fonte da mudana para a famlia
de funes que os servem. De acordo com que suas necessidades mudam,
aquela famlia de funes tambm deve mudar para adaptar-se s suas
necessidades.
1) Princpio da Responsabilidade nica

Se analisarmos a imagem, veremos como o Princpio da Responsabilidade nica respeitado. A

criao de objetos est separada na direta, em Fbricas (Factories) e no ponto de entrada principal
(Main) de nossa aplicao, um ator uma responsabilidade. A persistncia tambm levada em
conta, na parte de baixo. Um mdulo separado para um responsabilidade diferente. Finalmente, na
esqueda, ns temos a apresentao ou o mecanismo de entrega, se assim preferir, no padro MVC
ou qualquer outro tipo de interface de usurio. A SRP foi respeitada novamente. S nos resta
descobrir o que fazer na nossa lgica de negcio.
1) Princpio da Responsabilidade nica

O Princpio da Responsabilidade nica deve sempre ser considerado quando for

codificar seus aplicativos. Projetos de classes e mdulos so bastante afetados
pela SRP, o que leva a um projeto com baixo acoplamento, com dependncias
menores e em menor quantidade. Mas, como qualquer moeda, ela tem duas
caras.

tentador codificarmos nossa aplicao, desde o comeo, com a SRP em mente.

Tambm bastante tentador identificar tantos atores quanto quisermos ou
precisamos - para no esquecermos de qualquer grupo de usurio desde o
comeo. Aplicar a SRP ao p da letra pode levar a uma otimizao prematura ao
invs de um projeto melhor, gerando um projeto difuso, onde as
responsabilidade das classes e mdulos so difceis de identificar ou entender.

Assim, toda vez que perceber que um mdulo ou classe comearam a mudar por
inmeras razes diferentes, no hesite, tome os passos necessrios para
respeitar a SRP, entretanto, no se deixe levar por ela, uma vez que otimizaes
prematuras podem enganar voc.
Princpio
do Aberto /
COTI Informtica
Fechado Escola de Nerds
2) Princpio do Aberto / Fechado

Entidades de software (classes, mdulos,

funes, etc.) devem ser abertas para
extenso mas fechadas para modificao.
Quando eu precisar estender o comportamento de um cdigo, eu crio
cdigo novo ao invs de alterar o cdigo existente.
2) Princpio do Aberto / Fechado

Extensibilidade
uma das chaves da orientao a objetos, quando um novo
comportamento ou funcionalidade precisar ser adicionado esperado
que as existentes sejam estendidas e e no alteradas, assim o cdigo
original permanece intacto e confivel enquanto as novas so
implementadas atravs de extensibilidade.
Criar cdigo extensvel uma responsabilidade do desenvolvedor
maduro, utilizar design duradouro para um software de boa qualidade e
manutenibilidade.

Abstrao
Quando aprendemos sobre orientao a objetos com certeza ouvimos
sobre abstrao, ela que permite que este princpio funcione. Se um
software possui abstraes bem definidas logo ele estar aberto para
extenso.
2) Princpio do Aberto / Fechado

Mas por que na prtica eu fecho para modificaes uma classe?

A razo simples: porque assim eu posso desenvolver meu software como se
fosse em camadas. Estando uma camada muito bem escrita e bem definida, eu
tenho certeza de que todas as classes derivadas tambm funcionaro bem.
As classes derivadas na prtica poderiam apenas usar os mtodos fechados e
acrescentar novos comportamentos ao sistema conforme novas necessidades
fossem surgindo.
Princpio da
Substituio
COTI Informtica
de Liskov Escola de Nerds
3) Princpio da Substituio de Liskov

Classes derivadas devem poder ser

substitudas por suas classes base
"Se voc pode invocar um mtodo q() de uma classe T (base),
deve poder tambm invocar o mtodo q() de uma classe
T'(derivada) que derivada com herana de T (base)."

Em outras palavras: "Uma classe base

deve poder ser substituda pela sua
classe derivada."
3) Princpio da Substituio de Liskov

O que isso quer dizer afinal?

Significa dizer que classes derivadas devem poder substitudas por

suas classes base e que classes base podem ser substitudas por
qualquer uma das suas subclasses. Uma subclasse deve
sobrescrever os mtodos da superclasse de forma que a
funcionalidade do ponto de vista do cliente continue a mesma.

O princpio da substituio de Liskov nos mostra que devemos

tomar cuidado ao fazer uso da herana, devemos verificar se o
polimorfismo faz mesmo sentindo, ou seja, se qualquer subclasse
pode ser utilizada no lugar da superclasse. Caso no, significa dizer
que a herana est sendo utilizada de forma inadequada.
3) Princpio da Substituio de Liskov

O WardsWiki formula e responde a seguinte pergunta: Por que o Princpio da Substituio de Liskov
importante?
Porque se no, as hierarquias de classe seriam uma baguna. Pois podem ocorrer comportamentos
estranhos quando uma instncia da subclasse for passada como parmetro para um mtodo.
Porque se no, testes de unidade para a superclasse nunca teria sucesso para uma subclasse.
A soluo
Temos disponveis vrias tcnicas para resolver ou evitar o problema de violao do princpio de
Liskov, onde podemos usar alguns padres de projeto no nosso cdigo e principalmente o
Composition instead Inheritance (evite herana, prefira composio).
Princpio da
Segregao
COTI Informtica
de Interface Escola de Nerds
4) Princpio da Segregao de Interface

O Princpio da Segregao de Interface trata da

coeso de interfaces e diz que clientes no devem
ser forados a depender de mtodos
que no usam.
O Princpio da Segregao de Interface nos alerta quanto
dependncia em relao a interfaces gordas, forando que
classes concretas implementem mtodos desnecessrios e
causando um acoplamento grande entre todos os clientes.

Ao usarmos interfaces mais especficas, quebramos esse

acoplamento entre as classes clientes, alm de deixarmos as
implementaes mais limpas e coesas.
4) Princpio da Segregao de Interface

Faa interfaces de fina granularidade, que sejam

especficas para quem vai utiliz-las;
Muitas interfaces especficas so melhores
do que uma nica interface geral.

Esse principio ajuda a evitar a criao de fat interfaces(interfaces gordas), termo

utilizado para interfaces com mais funcionalidades do que o necessrio. Classes que
implementam uma interface assim no so coesas.

As interfaces podem ser divididas em grupos de mtodos, e cada grupo atende uma
conjunto diferentes de classes, cada classe pode implementar apenas as
funcionalidades que fazem sentido;

Uma dos indicadores para identificar a quebra deste principio no seguinte cenrio
voc ter uma interface com 4 funcionalidades porm ao implementar essa interface
em uma classe faz sentido todas os mtodos. Porm em outra classes uma
funcionalidade ou outra no faz sentido ser implementada.
4) Princpio da Segregao de Interface

Uma boa dica para evitar a quebra desse principio sempre que adicionar um
mtodo em uma interface, analise quem implementa essa interface e se
aquele mtodo faz sentido para todas as classes que implementam. Se tiver
sentido adicione nessa interface sem nenhum problema, caso no faa sentido
crie um outra interface(ou verifique se faz sentido em outra interface j
existente) para adicionar o mtodo que voc precisa implementar.

Indicadores de quebra do principio:

Mtodos de classes, implementados com base em uma interface, retornando

valores padres ou jogando excees
Implementaes de mtodos que no fazem sentido para a classe
Pouco sentido nas interfaces que existem no sistema
Muita alteraes no cdigo para adicionar um novo mtodo na interface.
Ao chamar um mtodo em uma classe no ter certeza se ele foi realmente
implementado(isso acontece e bastante)
Princpio da
Inverso de
COTI Informtica
Dependncia Escola de Nerds
5) Princpio de Inverso de Dependncia

Mdulos de alto nvel no devem depender de mdulos

de baixo nvel. Ambos devem depender de abstraes;

Abstraes no devem depender de detalhes. Detalhes

devem depender de abstraes.
5) Princpio de Inverso de Dependncia

Inverter a dependncia faz com que um cliente no fique frgil a mudanas

relacionadas a detalhes de implementao.
Isto , alterar o detalhe no quebra o cliente. Alm disso, o mesmo cliente pode ser
reutilizado com outro detalhe de implementao.

O Princpio da Inverso de Dependncia um dos pilares para uma boa arquitetura de

software, focada na resoluo do problema e flexvel quanto a detalhes de
implementao, como bancos de dados, servios web, leitura/escrita de arquivos, etc.

Este princpio refora que a abstrao est mais relacionada ao seu cliente do que ao
servidor (a classe que realiza a abstrao). No exemplo ilustrado acima, Dispositivo (a
abstrao) est diretamente ligado ao cliente (Botao). Sua implementao (Lampada)
um mero detalhe.

Sendo assim, Dispositivo ficaria no mesmo pacote (ou componente) do Botao e no

junto com sua implementao Lampada. (Esta separao de interface e implementao
em componentes distintos um padro conhecido por Separated Interface, como
catalogado no livro PoEAA, do Martin Fowler.)
5) Princpio de Inverso de Dependncia

Outro exemplo bem comum deste padro est no uso do padro Repositrio. Neste
caso, aplicamos o DIP para que nosso domnio dependa de uma abstrao do
Repositrio, ficando totalmente isolado de detalhes sobre persistncia

O Princpio da Inverso de Dependncia um princpio essencial para um bom design

orientado a objetos, ao passo que o oposto leva a um design engessado e procedural.
Identificar abstraes e inverter as dependncias garantem que o software seja mais
flexvel e robusto, estando melhor preparado para mudanas.
CONCLUSO
Utilizar estes princpios, aplicando-os corretamente, nos levar a ns
programadores a criar classes muito mais eficientes, de cdigo muito mais
limpo e de fcil compreenso e manuteno. Desenvolver sistemas vai muito
alm de apenas escrever cdigos.