Principios SOLID – Principio da Responsabilidade Única

Hoje iremos falar sobre os princípios SOLID, que são boas praticas que o profissionais de desenvolvimento definiram com décadas de experiencia em Engenharia de Software.

São 5 princípios que o compõe e a primeira letra de cada um que define o acrônimo S.O.L.I.D.
[S]ingle Responsability Principle
[O]pen/Closed Principle
[L]iskov Substitution Principle
[I]nterface Segregation Principle
[D]ependency Inversion Principle

Estes principios, quando bem aplicados, ajudam a evitar os problemas de design da nossa aplicação, permitindo a maior facilidade de manutenção.

Mas como o SOLID é muito extenso para ser tratado em um post, iremos hoje falar do primeiro item que compõe o acrônimo, o SRP, ou Princípio da Responsabilidade Única.

Este princípio nada mais é do que uma perspectiva diferente para um dos mais fundamentais princípios da orientação a objetos: a coesão.

O princípio da responsabilidade única é focado na discussão entre as classes de um sistema e nas suas responsabilidades.

Uma responsabilidade é uma tarefa ou ação que a classe deve realizar, e para que o sistema possa estar de acordo com esse princípio, cada classe deve possuir apenas uma única responsabilidade.

Alguns problemas de não seguir o SRP:

– Dificuldade de compreensão e, portanto, dificuldade de manutenção.

– Dificuldade de reuso.

– Acoplamento alto

Exemplo de violão da SRP:

public class Pedido
{
public void AdicionarProduto(Produto produto, int quantidade) { }
public decimal CalcularTotal() { }
public void GerarPlanilhaExcel() { }
}

No exemplo acima, temos uma quebra do principio, pois de forma bem explita, a classe realiza algo que não deveria. Os dois primeiras métodos fazem sentido no contexto da classe. Já o terceiro, está relacionado a geração de um formato de exibição específico que provavelmente deveria ficar em outro lugar (como na camada de aplicação, ao vez da camada de domínio).

Em um projeto com várias classes seguindo esse “padrão”, fica difícil quase impossível manter a coesão. Em outras palavras, o software acaba sendo um emaranhado de classes sem um divisão clara de camadas, dificultando a manutenção do software.

Um outro exemplo da não aplicação SRP seria misturar as classes de negócio e a persistência. Isso foi feito por muito tempo e aposto que até hoje muito sistemas que estão na ativa ainda utilizam.

Resumindo, esse princípio, que é muito importante em OO, faz muita diferença na hora na manutenção do software. Sendo essa a etapa mais longa do ciclo de vida de software e para mim o principal motivo para abandono da sistema e criação de um novo.

Fonte: http://www.devmedia.com.br/utilizacao-dos-principios-solid-na-aplicacao-de-padroes-de-projeto-revista-engenharia-de-software-magazine-50/25369

Advertisements

Lezel ur respont

Fill in your details below or click an icon to log in:

Logo WordPress.com

Emaoc'h oc'h ober un evezhiadenn gant ho kont WordPress.com Log Out / Kemmañ )

Skeudenn Twitter

Emaoc'h oc'h ober un evezhiadenn gant ho kont Twitter Log Out / Kemmañ )

Luc'hskeudenn Facebook

Emaoc'h oc'h ober un evezhiadenn gant ho kont Facebook Log Out / Kemmañ )

Google+ photo

Emaoc'h oc'h ober un evezhiadenn gant ho kont Google+ Log Out / Kemmañ )

War gevreañ ouzh %s