SOLID

Nesse post vamos falar de SOLID, os cincos princípios básicos da programação orientada a objeto. Quando esses princípios são aplicados em conjunto no desenvolvimento de software temos a intenção de criar um sistema que seja fácil de manter e de estender ao longo do tempo.

Mas o que significa SOLID?

SOLID é o mnemônico de  (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion).

Single Responsibility: 

Ter a noção que um objeto deve ter apenas uma responsabilidade, apenas uma razão de existir.

Nesse caso estamos afirmando que cada objeto de ter uma única responsabilidade, e que a responsabilidade deve ser encapsulada pela classe.

Open-Closed: 

Ter a noção que as entidades de software devem ser abertas para extensão, mas fechadas para modificação.

Nesse caso objetos devem ser abertos para extensão, mas fechados para modificação.

Para entender um pouco sobre esse tema podemos pensar em um classe onde temos um método sendo utilizado em produção, para não impactar o código com possíveis bugs, podemos criar um novo método (overload) assim estamos extendendo a classe e não modificando sua razão de existir.

Liskov Substitution: 

Ter a noção de que os objetos em um programa devem ser substiuíveis com instâncias de seus subtipos, sem alterar a correção desse programa.

Noção Liskov de um subtipo comportamental define uma noção de substituição para mutáveis ​​objectos, isto é, se S é um subtipo de T , em seguida, objectos do tipo T de um programa pode ser substituído com objectos do tipo S sem alterar qualquer uma das propriedades desejáveis ​​de que o programa (por exemplo, correção ).

Subtipagem comportamental é uma noção mais forte que o normal subtipagem de funções definidas na teoria dos tipos , o que depende apenas do contravariance de tipos de argumentos e de covariância do tipo de retorno. Subtipagem comportamental é trivialmente indecidível em geral: se q é a propriedade "método de x sempre termina ", então é impossível para um programa (compilador) para verificar se ele é válido para algum subtipo S de T mesmo q é válida para T . O princípio é útil no entanto, em raciocínio sobre o projeto de hierarquias de classe.

Interface segregation: 

Ter a noção de que muitas interfaces de cliente específicos são melhores que interfaces de uso geral.

É um princípio de desenvolvimento de software utilizado para o desenvolvimento limpo e destina-se a ajudar os desenvolvedores a evitar que seu software seja impossível de mudar. Se for seguido, o ISP vai ajudar um sistema ficar dissociado e, portanto, mais fácil de refatorar, mudança e reimplantar. O ISP diz que uma vez que uma interface tornou-se demasiada "complexa" ela precisa ser dividida em interfaces menores e mais específicas para que todos os clientes da interface só vão saber sobre os métodos que pertencem a eles. Em suma, nenhum cliente deve ser forçado a depender de métodos que não utilizam.

Dependency Inversion: 

Ter a noção que devemos depender das abstrações.

Na programação orientada a objetos , o princípio da inversão dependência refere-se a uma forma específica de desacoplamento onde convencionais dependência relações estabelecidas a partir de alto nível, de definição de políticas módulos de baixo nível, os módulos de dependência é invertida (ou seja, revertidos) para a finalidade de prestar alta nível módulos independentes dos detalhes de baixo nível implementação do módulo. Os estados principais:

A. módulos de alto nível não devem depender de baixo nível módulos. Ambos devem depender de abstrações.

B. Abstrações não devem depender de detalhes. Detalhes devem depender de abstrações

 Bom esse assunto é muito mais amplo do que tratamos neste post, mas espero ter dado uma noção desses principios para o desenvolvimento de um sistema bem projetado.

até mais.