Injeção de Dependência

Princípios S.O.L.I.D

Dentro dos princípios S.O.L.I.D. temos os seguintes itens:

Single Responsability Principle

A class should have one, and only one, reason to change.

Robert C. Martin

Esse primeiro princípio diz que “uma classe deve ter apenas um motivo para mudar”, ou seja, deve ter uma única responsabilidade.

Basicamente, esse princípio trata especificamente a coesão. A coesão é definida como a afinidade funcional dos elementos de um módulo. Se refere ao relacionamento que os membros desse módulo possuem, se possuem uma relação mais direta e importante. Dessa forma, quanto mais bem definido o que sua classe faz, mais coesa ela é.

Open/Closed Principle

You should be able to extend a classes behavior, without modifying it.

Robert C. Martin

No princípio do Open-Closed Principle diz que “as entidades de software (classes, módulos, funções etc.) devem ser abertas para ampliação, mas fechadas para modificação”.

De forma mais detalhada, diz que podemos estender o comportamento de uma classe, quando for necessário, por meio de herança, interface e composição, mas não podemos permitir a abertura dessa classe para fazer pequenas modificações.

Liskov Substituion Principle

Derived classes must be substitutable for their base classes.

Robert C. Martin

Se S é um subtipo de T, então os objetos do tipo T, em um programa, podem ser substituídos pelos objetos de tipo S sem que seja necessário alterar as propriedades deste programa.

Interface Segregation Principle

Make fine grained interfaces that are client specific.

Robert C. Martin

No princípio da Segregação de Interfaces (ISP) diz que “muitas interfaces específicas são melhores do que uma interface geral” que se trata da coesão em interfaces, da construção de módulos enxutos, ou seja, com poucos comportamentos.

Interfaces que possuem muitos comportamentos são difíceis de manter e evoluir, e devem ser evitadas.

Dependency Inversion Principle

Depend on abstractions, not on concretions.

Robert C. Martin

Devemos “depender de abstrações e não de classes concretas”:

Acoplamento e Coesão

Acoplamento

Acoplamento é o grau de interdependência entre módulos de software.

Um auto grau de acoplamento implica que mudanças em um módulo podem refletir em outro módulo acoplado.

Quanto maior o acoplamento, menor a interdependência, a coordenação e mais turbulento é o fluxo das informações.

Baixo acoplamento, geralmente indica um sistema bem estruturado e mais fácil de desenvolver, evoluir e dar manutenção.

Coesão

É um princípio ligado ao S do SOLID, e reforçando a idéia, indica que uma classe tem apenas uma responsabilidade e deve fazê-la bem. Não deve assumir responsabilidades que não são suas.

Quanto mais coesa uma classe é, mais independente ela é.

Herança vs Composição

Herança

Quando se estuda OOP, a herança faz parte do roteiro, porque é um dos pilares principais.

Entretanto, a herança também traz um efeito colateral, aumentando o acoplamento e dificultando testes, e aumentando complexidades.

Normalmente, é preferível trabalhar com composição, onde uma classe que tem ações que podem ser especializadas, o façam usando outras classes independentes que são injetadas automaticamente.

Assim, mantemos as classes o mais enxutas possível.