Tuesday, October 30, 2012
S.O.L.I.D.
SOLID é uma sigla que apresenta 5 princípios básicos da programação orientada a objetos:
Estes princípios básicos servem como guias para o desenvolvimento de um código sustentável e eficiente. Para projetos que implementam o TDD e metodologias ágeis de gerenciamento estes princípios são essenciais.
Abaixo, temos uma introdução de cada um dos princípios
Single Responsibility:
"Every class should have a single resposibility. It should have a single puprpouse in the system, and there should be only one reason to change it." - Michael C feathers
Este é o princípio da responsabilidade única, cada classe no sistema deve ter um único objetivo. É um princípio que prega a coesão do sistema:
Coesão
A coesão Mede o quanto que uma classe e seus métodos fazem sentido;
Uma classe com alta coesão possui responsabilidades bem definidas e são difíceis de serem desmembradas em outras classes;
Uma classe com baixa coesão possui muitas responsabilidades, geralmente que pertencem a outras classes, e podem ser facilmente desmembradas em outras classes;
Open Closed:
Introduzido por Bertrand Meyer no seu livro Object Oriented Software Contruction - http://en.wikipedia.org/wiki/Object-Oriented_Software_Construction, este princípo diz que o código do sistema deve ser extensível (voltamos a coesão) e fechado para modificação. Ou seja, uma entidade deve permitir que o seu comportamento se modifique sem que o código seja alterado.
A idéia mais importante é que uma classe só deve ser alterada para correção de erros. Funcionalidades alteradas e novas devem ser criadas em classes novas que implementam o conceito de herança. Evitando modificações, reduzimos a carga de revisão, testes unitários, integrados, etc..
Liskov substitution principle
"Objects of subclasses should be substitutabe for objects of their superclasses througout our code. If they are not, we could have silent errors in our code."
Princípio da substituição de Liskov. Se um objeto B implementa herança do objeto A, então o sistema deve permitir que o objeto A seja substituído por B. Por exemplo:
public class Nota {
int valor;
}
public class DezReais: Nota {
public DezReais()
{
this.valor = 10;
}
}
public class VinteReais: Nota {
public VinteReais()
{
this.valor = 20;
}
}
Neste caso temos as classes DezReais e VinteReais que implementam herança da classe Nota. Podemos então ter uma lista de objetos do tipo Nota, que são substituídos por objetos do outro tipo.
var notas = new List<Nota>();
notas.Add(new DezReais());
notas.Add(new VinteReais());
Interface Segregation principle
O princípio da segregação de interfaces diz que os clientes não devem depender de interfaces que não são usadas por eles, ou seja, nossas interfaces devem ser o mais coesas possível, minimizando o aclopamento do sistema.
O conceito foi introduzido por Robert Martin (vulgo uncle bob), e apresentado através do exemplo de um projeto de software desenvolvido para uma impressora da Xerox.
Neste projeto, os clientes dependiam de uma única classe gigante de job. Para resolver este problema, foi criada uma camada de interfaces entre a classe gigante e os clientes, usando o princípo de inversão de dependência. Agora cada cliente faria acesso a sua própia interface, que é implementada pela classe gigante, escondendo os métodos que não dizem respeito a este cliente.
Dependency inversion principle
O princípio de inversão de dependência diz que as classes do nosso projeto devem depender de abstrações e não de implementações concretas.
Por exemplo:
public class CartaDeBaralho()
{
}
public class Ordenador()
{
public void Ordena( List<CartaDeBaralho>) {}
}
No exemplo de código acima, a classe Ordenador depende da implementação de CartaDeBaralho.
O ideal seria a classe Ordenador depender de uma interface. Isto evita duplicação de código através da reutilização, deixando a lógica de comparação para cada uma das entidades que implementarem a interface (de volta a coesão). Por exemplo:
public interface IOrdenavel()
{
void Compara();
}
public class CartaDeBaralho(): IOrdenavel
{
public void Compara()
{
}
}
public class Ordenador()
{
public void Ordena( List<IOrdenavel>) {}
}
Good stuff:
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
http://www.slideshare.net/ydarias/solid-principles-9721480
Labels:
arquitetura,
dependency,
design,
interface,
inversion,
liskov,
mdd,
oo,
pattern,
segregation,
software,
solid,
substitution
Subscribe to:
Post Comments (Atom)

No comments:
Post a Comment