Princípios de Design de Software – Single Responsibility Principle

No post anterior foi feita uma pequena introdução sobre o que é Design de Software, principalmente do ponto de vista dos Métodos Ágeis. Ao final do post comentamos brevemente sobre os princípios de Design de Software conhecidos como SOLID. Então nesta série de posts vamos comentar sobre cada um deles, começando com o Single Responsibility Principle (SRP)

Single Responsibility Principle

Este princípio diz que cada classe deve ter apenas uma responsabilidade[1]. Quando várias responsabilidades são agregadas em uma única classe, mudanças em uma destas pode ocasionar problemas com as outras responsabilidades.

Em [1], Martin mostra um excelente exemplo de como este princípio é quebrado, os possíveis efeitos colaterais e como melhorar o design das classes.

O exemplo é simples, um sistema que precisa representar um retângulo, que será então utilizado por outros dois subsistemas: um que faz computações geométricas com os retângulos e outro que trabalha com aplicações gráficas. Observe o diagrama a seguir, exibido em [1]:

É construída uma classe Retângulo com dois métodos básicos: draw e area. A princípio parece não haver nenhum problema com o design acima, o subsistema que trabalha com gráficos com certeza utiliza o método de desenho e, eventualmente, pode realizar alguma computação geométrica. No entanto a aplicação que faz computação geométrica não vai utilizar o método de desenho.

O problema maior ocorre quando é feito o deploy da aplicação. Imagine que o sistema é feito em C++, todas as bibliotecas gráficas seriam lincadas com a aplicação geométrica, causando perca no desempenho do sistema. Se for uma aplicação Java, os arquivos .class das bibliotecas gráficas seriam também entregues junto com a aplicação de computação geométrica, mesmo que ela nunca utilize os métodos gráficos [1].

Além disso, se a aplicação gráfica causar alguma mudança na classe retângulo será necessário construir, testar e refazer a operação de deploy da aplicação de computação geométrica para garantir que as alterações não afetem este subsistema. Martin sugere então a seguinte alteração no design desse exemplo [1]:

Com este novo design é feita a separação das responsabilidades de computação geométrica e de desenho, deixando os subsistemas relacionados apenas com o que é realmente necessário.

Martin também explica em [1] que responsabilidade pode ser entendida como razão para mudança, ou seja, quando uma classe tem mais do que um motivo para mudar, quer dizer que ela tem mais que uma responsabilidade. Pelo simples exemplo acima é possível ver todos os problemas que o não respeito deste princípio pode trazer.

Padrões de Projeto

Observando os padrões de projeto, é fácil notar que quase todos os padrões procuram seguir este princípio. Observando, por exemplo, o padrão Strategy é fácil ver que, com a separação do comportamento e do contexto, busca-se separar as responsabilidades. Assim as mudanças são feitas localmente e dificilmente irão se propagar ao longo do sistema. De maneira similar, o padrão Visitor também busca separa operações do conjunto de dados. Os padrões Adapter e Bridge também buscam separar as abstrações das implementação, dando maior flexibilidade ao sistema.

Quase todos os padrões buscam melhorar o design e separar as responsabilidades. Outro bom exemplo são os padrões de criação, que assumem a responsabilidade de criação de objetos, deixando o cliente livre desta responsabilidade.

Para saber mais sobre o princípio SRP é possível analisar os padrões de projeto e observar como as responsabilidades são divididas entre todas as classes, bem como analisar outros design de sistemas que sigam o princípio. Como comenta Martin em [1], este princípio é um dos mais simples para entender, mas um dos mais difíceis para seguir.

Uma boa referência sobre o padrão é o material de Martin [1], bem como todas as outras referências comentadas no post sobre Design de Software.

Se gostou do post compartilhe com seus amigos e colegas, senão, comente o que pode ser melhorado. Possui alguma outra opinião ou alguma informação adicional? Comenta ai! 😀

Referências:

[1] http://www.objectmentor.com/resources/articles/srp.pdf

Anúncios

2 comentários sobre “Princípios de Design de Software – Single Responsibility Principle

  1. […] você não conhece o Princípio da Responsabilidade Única (Single Responsibility Principle), veja esse outro post que tem mais […]

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s