DevMedia
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login

Arquitetura - O Princípio da responsabilidade única

O princípio da responsabilidade única é um dos princípios SOLID. Os princípios SOLID, são uma série de cinco princípios introduzidos por Robert C. Martin( Uncle bob ),como boas práticas de design de software. O princípio da responsabilidade única, foca na preocupação de que uma classe tenha seu papel e venha desempenhar somente ele de forma eficiente.

[fechar]

Você não gostou da qualidade deste conteúdo?

(opcional) Você poderia comentar o que não lhe agradou?

Confirmo meu voto negativo
    Muito tenho falado sobre boas práticas de engenharia de software. Aplicar boas práticas, nos rende muitos benefícios como manutenção facilitada, um código organizado, dependências mais leves e uma arquitetura pronta para “abraçar” as mudanças, ao invés de brigar com elas. Hoje estarei abordando um dos princípios SOLID, que são princípios que foram introduzidos por Robert C. Martin, ou como é comumente chamado Uncle Bob. Os princpipios SOLID,  são cinco princípios de engenharia de software para alcançar os benefícios que falamos anteriormente. Ficou famoso como SOLID, por que são as iniciais dos princípios, e o pessoal percebeu que formava a palavra SOLID e passou a usá-la. Veja abaixo:
Principios SOLID
·         S  - Sigle Responsability Principle
·         O - Open Close Principle
·         L  - Liskov substitution Principle
·         I  -  Interface segregation principle
·         D – Dependency inversion principle
 
    Estaremos abordando neste artigo o Sigle responsability principle.
 
Combatendo a Classes faz tudo

     Uncle bob diz eu seu livro clean code, que se uma classe tem mais de um motivo para ser alterada ela já está ferindo o princípio da responsabilidade única. As classes devem ter apenas uma responsabilidade, realizar somente ela e realizá-la bem. Observe o diagrama abaixo:

    O que você vê de arrado na classe acima? Concorda que ela esta assumindo responsabilidades que não são suas? Concorda que ela esta fazendo coisas demais? Ela além de suas propriedades, obtem por id, obtem por nome e ainda salva; diriamos que é uma geniuna classe “canivete suiço”. E geralmente, um modelo de um sistema não tem somente uma classe, mais várias e se  todas estivessem assim? Teriamos vários problemas, para dar manutenção e evoluir. Agore veja o exemplo abaixo, refatorado e contemplando o princípio da responsabilidade única.
 
 
    Note que temos um cenário completamente diferente, desacolplado e com cada “peça” realizando somente o seu papel. Temos uma classe Entidade, imaginando que estejamos seguindo as premissas do DDD( Domain Drive Design ), uma classe produto que herda de entidade e possui propriedades comuns a todos os produtos, como por exemplo nome e fabricante e classes que herdam de produto e tem suas particularidades em cada uma delas; note que estas classes possuem apenas propriedades e poderiam também, ter métodos e eventos, mais que tratassem apenas do negócio e não de persistência como vimos no exemplo anterior. Na hora de persistir, temos classes apropriadas que vão pegar este objeto de negócio e salvar no banco de dados, ou no repositório destinado a armazená-los. Lembrando que estamos utilizando um padrão de arquitetura chamado repository pattern.
     
O Mandamento do princpipio da responsabilidade única
     Uma classe deve fazer apenas uma coisa, deve fazê-la bem e deve fazer somente ela. Se uma classe tem mais de um motivo para ser alterada, ela não segue este princípio. Se ao se referir a uma determinada classe, você diz por exemplo: “minha classe tem as informações do cliente e salva o mesmo no banco de dados” perceba que o “e” na frase, indica mais de uma responsabilidade, ferindo assim o SRP( single responsability rpinciple ).
     Aplicar o princípio da responsabilidade única, é importante para uma arquitetura madura e sustentável. Quando começamos a dar valor a princípios como este, vemos que estamos amadurecendo e fazendo melhor o que gostamos de fazer: software.
    Bom pessoal espero que eu possa ter ajudado, e colaborado em algo com o crescimento profissional de cada leitor deste artigo. Um abraço e até a próxima.


Analista Desenvolvedor atuando no mercado a mais de 6 anos.Atualmente prestando serviço para grande empresa de telefonia

O que você achou deste post?
Conhece a assinatura MVP?
Serviços

Mais posts