Princípios SOLID

Dyego Costa

{ Princípios SOLID }

SOLID

SRP

OCP

LSPISP

DIP

SOLID

SingleResponsibility

OpenClosed

LiskovSubstitution

InterfaceSegregation

DependencyInversion

{ Single Responsibility Principle }

O princípio de responsabilidade única diz que todo objeto deve ter uma única responsabilidade, e que a

responsabilidade deve estar encapsulada pela classe.

Nunca deve existir mais de um motivo para que uma classe mude.

Robert C. “Uncle Bob” Martin

< SRP >

Só porque você pode, não quer dizer que deve

{ Acoplamento vs. Coesão }

coesão

A coesão é definida, em termos acadêmicos, como a medida de proximidade no relacionamento entre

todas as responsabilidades, os

dados e os métodos de uma classe.

“maior = melhor”

acoplamento

O acoplamento entre classes ou subsistemas é

uma medida da interconexão entre essas classes ou subsistemas.

“menor = melhor”

demonstração

{ Open/Closed Principle }

O princípio Aberto/Fechado diz que toda entidade de software (classe, função, módulos, etc) deve estar aberta para extensão e fechada

para modificação.

< OCP >

demonstração

{ Liskov Substitution Principle }

“Se para cada objeto o¹ do tipo S existe um objeto o² do tipo T que para todos programas P definidos em termos de T, o

comportamento de P é imutável quando o¹ é substituído por o². Então S é um subtipo de T.”

Barbara Liskov

< LSP >

“Funções que usam referências para classes bases devem ser capazes de usar objetos de classes derivadas sem estar

ciente disso.”

Robert C. “Uncle Bob” Martin

Pré-condições e pós-condiçõesPré-condição não deve ser fortalecida e a pós-condição não deve ser enfraquecida.

InvariânciaSe a condição de um processo é verdadeiro na classe base deve permanecer verdadeiro na subclasse.

Histórico de contratoAs subclasses devem implementar todos os membros de suas classes base.

{ Regras }

{ demonstração }

{ Interface Segregation Principle }

O Princípio da Segregação de Interface afirma que os clientes não deveriam ser forçados a depender de interfaces que eles

não usam.

< ISP >

{ demonstração }

{ Dependency Inversion Principle }

Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações. Em segundo lugar, abstrações não devem depender de detalhes. Detalhes devem depender de abstrações.

< DIP >

demonstração

Containers de Dependency

Injection

Ninject

Unity

Castle

Windsor

StructureMap

{ Referências / Dicas }

http://dimecast.net

http://pluralsight.com

http://blackwasp.co.uk

http://dofactory.com

http://codebetter.com