13 de novembro de 2016


De acordo com Tom DeMarco (1979), não deve haver mais de um motivo para uma classe ser alterada. Esse é o SRP, Princípio da Responsabilidade Única. Esse princípio garante que uma classe deve ser implementada para cumprir um único objetivo. Caso essa classe tenha mais de um motivo para mudar, significa que ela está fazendo mais coisas do que deveria. Isso pode indicar que essa classe deve ser dividida para gerar novas classes e dividir esses objetivos. O problema de uma classe assumir mais de uma responsabilidade é que quanto mais responsabilidades ela assume, mais complexa ela se torna no sentido de que, quanto maior a quantia de responsabilidades, maior será a dimensão de possíveis alterações. Nesse caso, quando for preciso realizar alguma alteração nessa classe mais complexa, haverá maior risco de impactar módulos que não necessariamente deveriam ser impactados. Por isso, o projeto se torna mais frágil quando contém módulos que não respeitam o princípio da responsabilidade única.


FIG. 1 Classe Retangulo ferindo SRP. Fonte: Bigonha.

Na Figura 1, podemos verificar a classe Retangulo, que possui o método desenha, o qual depende de GUI. Aplicação Geometrica só necessita utilizar o método area mas, possui o GUI disponível mesmo sem necessitar utilizá-lo. A aplicaçao grafica, por sua vez, teria disponível o método para calcular área, mesmo sem necessitar utilizar esse método. Essa classe deveria ser dividida, pois, possui duas responsabilidades em vez de uma.




FIG. 2 Refatoração SRP. Fonte: Bigonha.

Na Figura 2 o problema ilustrado pela Figura 1 foi corrigido. A classe Retangulo foi dividida e criou-se também a classe RetanguloGeometrico. Agora as alterações na representação gráfica não vão afetar a aplicação geométrica, e as alterações no cálculo da área não irão afetar a aplicação gráfica.

Manter as classes com objetivos únicos torna o código mais fácil de ser entendido. Quando necessário, será mais rápido realizar também a sua manutenção. “Se uma classe tem mais de uma responsabilidade, então haverá mais de uma razão para alterá-la”. Nesse caso, quanto maior a ocorrência de classes com mais de uma responsabilidade, maior será a fragilidade do sistema uma vez que, se a classe apresentar algum problema ela afetará uma parte maior que ela afetaria se não possuísse mais de uma responsabilidade.

Referência:

DEMARCO, T. Structured Analysis and System Specification. 1. ed. New Jersey: Prentice Hall, 1979.


0 comentários:

Postar um comentário

Comentários:

Perfil

Formada em Sistemas de Informação e pós-graduada em Engenharia de Software.

Facebook

Views